Techniques for Processing Wireless Broadcast Packets from Medical Devices with Usage-Related Data

Abstract

A computing device is provided having a processor in communication with a memory configured to store machine-readable instructions. The processor can receive from a wireless communication interface of the medication delivery device an advertising packet including injection event information generated by the medication delivery device, analyze context data associated with the advertising packet to determine validation data, and select between performing any two or three of the following actions based on the validation data: (i) including the injection event information in a medication log, (ii) prompting a user for additional information, or (iii) ignoring the advertising packet. The medication delivery device includes (a) a reservoir configured to hold a medication, (b) an activation button for initiating injection of the medication, and (c) a processing circuit in communication with the wireless communication interface.

Description

Background Art

[0001] Syringe forms or injection devices including syringes are widely used by medical professionals and self-administering patients. Patients suffering from several different diseases may sometimes inject themselves with drugs frequently, and various devices have been developed to facilitate such self-treatment. In one example, the use of an auto-injection device including a mechanism for performing some of the steps of the injection process makes self-treatment more convenient for patients, especially those with limited manual dexterity. The auto-injection device can be a single-use device that is disposed of after use.

[0002] Many syringe pens and other drug delivery devices do not include a function for automatically detecting and recording the occurrence of an injection event. In the absence of an automated system, patients must manually track the time of each injection. Accordingly, the inventors recognized the need for a system that can automatically and accurately detect and record information regarding the occurrence of an injection event.

Summary of the Invention

[0003] The present disclosure relates to techniques for receiving injection event information from a drug delivery device. In some embodiments, the technique can analyze context data associated with a wireless transmission packet (e.g., an advertising packet) to determine (i) whether to store the injection event information (e.g., in a dosing log on a computing device without prompting the user to confirm such storage), (ii) whether to prompt the user for additional information (e.g., prompt the user to confirm whether to store the injection event information on the computing device), or (iii) whether to ignore the wireless transmission packet (e.g., by taking no further action and not performing either (i) or (ii)).

[0004] In one embodiment, the technique is to receive, from a wireless communication interface of a drug delivery device, an advertising packet including injection event information generated by the drug delivery device, wherein the drug delivery device comprises (a) a reservoir configured to hold a drug, (b) an activation button for initiating injection of the drug, and (c) a processing circuit communicating with the wireless communication interface, the receiving, analyzing context data associated with the advertising packet to determine verification data, and based on the verification data, determining (i) whether to include the injection event information in a dosing log, (ii) whether to prompt the user for additional information regarding the advertising packet, or (iii) whether to ignore the advertising packet, to provide a computerized method.

Brief Description of the Drawings

[0005] The features mentioned above in this disclosure, as well as other features, and the manner in which they are achieved, will become more apparent by referring to the following description of embodiments of the disclosure in conjunction with the accompanying drawings, and the invention itself will be better understood.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

[0006] To facilitate understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and these embodiments will be described using specific language. Nevertheless, it will be understood that no limitation of the scope of the invention is thereby intended.

[0007] The present disclosure relates to software-based techniques for processing data received from a drug delivery device. According to some embodiments, the techniques can log information regarding a drug delivered to a patient, such as the time of an injection event, the date of the injection event, the dosage of the injection event, and / or other injection or dosage-related data. Logging injection event information can help a patient track dosing information over time. Such dosing information can be used, for example, to plan a dosing schedule, such as to determine when to take the next dose of a drug, what type of drug to take for the next dose, and / or how much of the drug to take for the next dose. Such dosing information can also be used by a patient's healthcare provider, payer, researcher conducting a clinical trial in which the patient is participating, or other interested entity to track a patient's compliance with a dosing regimen over time. The inventors recognized that automatically logging injection data received from a drug delivery device can improve the accuracy and precision of a dosing log and reduce the burden on the user, because the user no longer has to manually track such information. Automatically logging dosing information can increase the accuracy of a dosing log, so automated dosage logging can help improve a patient's compliance with a dosing regimen. In the context of a clinical trial, understanding more precisely when dosing occurs can help with efficacy analysis and determination of an appropriate dosing regimen. Further, using such software-based techniques can enable researchers to remotely access a dosing log, eliminating the need for a patient to come to a centralized clinic, which can ultimately lead to a shortening of the clinical trial and a shortening of the time to productization. According to some embodiments, the techniques can receive injection event information through wireless packets, such as advertising packets, broadcast by a drug delivery device. Many protocols for wirelessly communicating data between a transmitting device and a receiving device require a handshake or pairing procedure between them to establish a wireless communication link or session between the transmitting device and the receiving device.However, as used herein, the term "advertising packet" is used to refer to a wireless transmission used by a transmitting device (e.g., a drug delivery device) to transfer data to a receiving device (e.g., a computing device such as a smartphone) without requiring any handshake or pairing process between the transmitting and receiving devices. The inventors understand that by using advertising packets, a user may not need to pair a drug delivery device with a computing device to process dosage information from the drug delivery device. In particular, since device pairing may require a user to perform multiple manual steps to complete the pairing process, avoiding such a pairing process can help reduce the overall burden on the user. Additionally, device pairing typically results in a computing device maintaining a record of previously paired devices to facilitate easier re-pairing in the future, so avoiding such a pairing process can reduce the use of memory within the computing device, which can be particularly useful when a user is expected to use many different drug delivery devices over a relatively short period of time. The inventors further understand that using advertising packets such as Bluetooth Low Energy (BLE) advertising packets can help improve the battery life of battery-powered drug delivery devices, as opposed to other wireless communication options.

[0008] The inventors understand that while there are advantages to using advertising packets that do not require a pairing process, relying on such packets can introduce unintended errors. For example, a computing device configured to process advertising packets having injection event information may accidentally receive an advertising packet from a different drug delivery device not associated with the user. For example, a patient in a public area may receive an advertising packet on their mobile phone from a drug delivery device belonging to another person using a similarly configured drug delivery device in the public area. As a result, automatically logging the data contained in the received advertising packet can lead to errors in the dosing log, such as logging data not associated with the patient. As a result, the patient may miss a dose of the drug and / or take a dose of the drug at a time earlier than prescribed.

[0009] To address these and other issues, the techniques described herein can analyze context data associated with a received advertising packet to determine whether it was correctly received (e.g., from a drug delivery device belonging to the patient) or may have been accidentally received (e.g., from a different drug delivery device belonging to a different patient). In some embodiments, the context data can include information about the advertising packet, information about the reception of the advertising packet, and / or information about the drug delivery device from which the advertising packet was broadcast. For example, a user may typically take a dose of a drug at a particular time of day. The computing device can analyze the reception time of the advertising packet to determine whether it aligns with the patient's typical dosing schedule. If the advertising packet is received at an irregular time, this may indicate that the advertising packet was accidentally received from a different drug delivery device.

[0010] According to some embodiments, based on the analysis of context data, the technique can determine whether to automatically process injection event information (e.g., log injection event information related to a patent), or ignore the advertising packet, or prompt the user for additional information to determine whether the received data should be processed for the user. In some embodiments, when it is likely that the advertising packet was correctly received from the patient's drug delivery device, the computing device can automatically log the injection event information in the dosing log without requiring further action by the user (e.g., without providing a verification prompt). As described above, automatically logging the information can minimize the burden on the patient. In some embodiments, when it is likely that the advertising packet was received incorrectly, the computing device can prompt the user to confirm whether to ignore the advertising packet or include the injection event information in the dosing log. Preventing potentially inaccurate information from being automatically included in the dosing log can help, for example, maintain the accuracy of the patient log, maintain the value of the patient log to the patient, and / or the like.

[0011] In one aspect, the drug delivery device includes a reservoir configured to hold a drug, an activation button to initiate injection of the drug, a wireless communication interface, and a processing circuit that communicates with the wireless communication interface. The computing device receives an advertising packet including injection event information generated by the drug delivery device from the wireless communication interface of the drug delivery device, analyzes context data associated with the advertising packet to determine verification data, and based on the verification data, is configured to determine (i) whether to include the injection event information in the dosing log, or (ii) whether to ignore the advertising packet, or whether to prompt the user for additional information regarding the advertising packet.

[0012] Although various embodiments have been described, it will be apparent to those skilled in the art that many more embodiments and implementations are possible. Accordingly, the embodiments described herein are examples and not the only possible embodiments and implementations. Further, the advantages described above are not necessarily the only advantages, and it is not necessarily expected that all of the described advantages will be achieved in each embodiment.

[0013] An exemplary drug delivery device or drug injection device 20 is illustrated in various operating states in FIGS. 1-3. Examples of such devices and their operation are disclosed in U.S. Patent No. 8,734,394 (B2) entitled "Automatic Injection Device with Delay Mechanism Including Dual Functioning Biasing Member" issued to Adams et al. on May 27, 2014, and U.S. Patent Application Publication No. 2021 / 0093784 (A1) entitled "Status Sensing Systems within an Injection Device Assembly" issued to Adams et al. on April 1, 2021, the entire disclosures of both of which are incorporated herein by reference. The device 20 includes a syringe assembly 22, a drive mechanism 24, and a retraction mechanism 26, and may include, for example, one or more main printed circuit boards (PCBs) 82 and / or one or more secondary PCBs 84 shown later in FIG. 4. The syringe assembly 22 includes a barrel 30 forming a container body for holding a drug, and a piston 32 disposed within the barrel 30 for driving the drug outside the barrel. The syringe assembly 22 also includes a needle assembly 33 having a hollow injection needle 34 and a needle hub 35 that attaches the needle 34 to the syringe barrel 30. Advancing the piston 32 within the barrel 30 toward the needle 34 dispenses the drug through the needle 34.

[0014] Devices described in this specification, such as device 20, may further contain a medicament, for example, within syringe barrel 30. In another embodiment, the system may include one or more devices including device 20 and a medicament. The term "medicament" includes, but is not limited to, insulin, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, GLP-1 receptor agonists such as dulaglutide or liraglutide, glucagon, glucagon analogs, glucagon derivatives, gastric inhibitory polypeptide (GIP), GIP analogs, GIP derivatives, oxyntomodulin analogs, oxyntomodulin derivatives, including, but not limited to, IL-23 antibody analogs or derivatives such as mirikizumab, IL-17 antibody analogs or derivatives such as ixekizumab, therapeutic antibodies, galcanezumab, drugs for treating pain such as lasmiditan, and any therapeutic agent that can be delivered by the above-described devices, and refers to one or more therapeutic agents. A medicament as used in the device may be formulated with one or more excipients. The device is generally operated in a manner as described above by a patient, caregiver, or healthcare professional to deliver the medicament to a human.

[0015] Figure 1 illustrates the device 20 in its initial pre-use configuration. Here, the end cap 36 is fixed to the injection device housing 38 and covers the proximal end opening 40 of the housing 38. As used herein, distal and proximal refer to the axial location relative to the injection site when the device is oriented for use at the injection site. Thus, for example, the proximal end of the housing refers to the end of the housing closest to such an injection site, and the distal end of the housing refers to the end of the housing farthest from such an injection site. The housing 38 is formed from a plastic material and can be shown to extend generally longitudinally between a distal end proximate to the actuation button 52 and a proximal end proximate to the proximal end opening 40 along the longitudinal axis 48. As shown in FIGS. 2 and 4, the housing 38 may include a user-grippable portion 37 configured to be gripped by the user's hand, and the user-grippable portion 37 extends outwardly from the longitudinal axis 48 by a radial distance 41. In some embodiments, the radial distance 41 may be 5 to 10 mm in length (e.g., in some embodiments, 5 to 8 mm may be a suitable length). Also, as shown in FIGS. 2 and 4, the housing 38 may also optionally include an end portion 39 that extends outwardly beyond the proximal end of the housing adjacent to the proximal end opening 40. The optional end portion extends outwardly from the longitudinal axis 48 by a radial distance 43 that is greater than the radial distance 41. In some embodiments, the radial distance 43 may be greater than 10 mm in length. For example, in some embodiments, the radial distance 43 may be 10 to 20 mm in length (e.g., in some embodiments, 15 to 20 mm may be a suitable length). The end portion 39 may smoothly slope radially outwardly from the user-grippable portion 37 as shown in FIGS. 1-3. In other embodiments, the end portion 39 may take other shaped forms. For example, the end portion 39 may take any shape that extends away from the longitudinal axis 48 by a radial distance 43 that is greater than the radial distance 41 of the user-grippable portion.

[0016] The needle guard 42 is mounted on the syringe assembly 22, covers, and surrounds the needle 34. The end cap 36 and the needle guard 42 protect the user from accidental needle sticks and also protect the needle 34 from damage. When using the device 20 to dispense a drug, for example, when injecting a drug into a patient, the end cap 36 and the needle guard 42 are first removed. FIG. 2 illustrates the device 20 after removing the end cap 36 and the needle guard 42 from the syringe assembly 22, with the syringe assembly in its retracted position and the device 20 ready for a dispensing event.

[0017] The syringe assembly 22 is movable relative to the injection device 20 between a retracted position and an injection position. FIG. 3 illustrates the device 20 after the syringe assembly 22 has been moved relative to the device 20 from its retracted position shown in FIG. 2 to the injection position. In the retracted position (FIGS. 1 and 2), the needle 34 is retracted to a position such that the needle 34 is disposed within the housing 38 of the device 20. In the injection position (FIG. 3), the needle 34 projects outwardly from the housing 38 beyond the proximal opening 40 in a proximal direction parallel to the longitudinal axis 48, whereby the needle 34 can be inserted into a patient.

[0018] The drive mechanism 24 includes a plunger 44 that engages with the piston 32. The drive mechanism 24 includes a spring 46 that drives the plunger 44 in a translational motion. In the illustrated embodiment, the spring 46 advances the plunger 44 along a linear path defined by the longitudinal axis 48 of the device 20. As the plunger 44 advances, the foot 50 of the plunger 44 contacts the piston 32. As the plunger 44 further advances, the syringe assembly 22 advances along the axis 48 from its stored position to its injection position. After the syringe assembly 22 has advanced to its injection position, continued proximal advancement of the plunger 44 advances the piston 32 proximally within the barrel 30 from its initial piston position (shown in FIGS. 1 and 2) to its final piston position (shown in FIG. 3) during the dispensing event, dispensing the medicament from the needle 34. Prior to any dispensing of the medicament and when the syringe barrel 30 holds the full volume of the original medicament, the piston 32 will be in its initial piston position. After advancing the piston 32 its entire travel length toward the needle assembly 33, the piston 32 will be in its final piston position proximate the needle assembly 33 and the medicament from within the barrel 30 will have been dispensed. For single use, the syringe assembly 22 will hold a single dose of the medicament to be delivered in a single injection event and the piston 32 will advance from its initial piston position to its final piston position during that single injection event, thereby delivering the entire single dose contents of the syringe assembly 22. Although the device is shown as a single use device, the device 20 can also be configured as a multiple use device with appropriate modifications.

[0019] The advancement of the plunger 44 will generally not result in the dispensing of the drug from the syringe assembly 22 until the syringe assembly 22 advances to the injection position. There are factors that can prevent the drug from being dispensed before the syringe advances to the injection position. The factor can be the friction between the piston 32 and the barrel 30. Typically, the piston 32 is formed of a rubber material and the barrel 30 should be glass. The frictional resistance between these two components can be sufficient to prevent the advancement of the piston 32 within the barrel 30 until the syringe assembly 22 advances to its injection position and engagement with a suitable stop member prevents further advancement of the syringe assembly 22. Additionally, the drug within the syringe is somewhat viscous and can thereby be somewhat resistant to flow out of the needle 34. Optionally, modifications to the piston 32 and the syringe barrel 30 to vary the frictional resistance of the dispensing movement of the engagement member 32 with respect to the syringe barrel 30 can limit or prevent premature dispensing of the drug before the container 22 reaches its injection position.

[0020] To activate the drive mechanism 24, the user presses the activation button 52 at the distal end of the device 20. By pressing the button 52, one or two elongated protrusions 54 on the plunger 44 are disengaged from the shuttle assembly 60, thereby enabling the spring 46 to axially advance the plunger 44. The spring 46 has a helical shape and surrounds the protrusion 54. The proximal end of the spring 46 is in biasing engagement with a flange 56 on the plunger 44.

[0021] The shuttle assembly 60 may include an upper shuttle member 62 and a lower shuttle member 64. The shuttle members 62, 64 are fixed together in the final assembly. In the final assembly, the upper shuttle member 62 captures the button 52 and the spring 46 and restricts the axial movement of these components in the distal direction. The protrusion 54 engages a surface on the upper shuttle 62 when the device is in the state shown in FIGS. 1 and 2. Pressing the button 52 engages a tab on the button 52 with the inclination of the protrusion 54, biases the protrusion 54 inwardly, and disengages the protrusion 54 from the upper shuttle member 62. After the protrusion 54 is disengaged, the spring 46 exerts a biasing force on the flange 56 and advances the plunger 44 from the position shown in FIG. 2 to the position shown in FIG. 3. As the plunger 44 advances, it moves the syringe assembly 22 to the injection position and then advances the piston 32 to dispense the drug as discussed above.

[0022] After the dispensing event is complete, the retraction mechanism 26 optionally moves the syringe assembly 22 back from the injection position shown in FIG. 3 to the retracted position. More specifically, the retraction mechanism is adapted to move the drug container from the injection position to the retracted position in a retraction movement. The retracted position may be similar to the storage position in that the syringe assembly is retracted into the housing 38, whereby the needle 34 no longer protrudes proximally from the proximal opening 40 and is disposed entirely within the housing 38. In some embodiments, the retracted position may be the same as the storage position. However, in other embodiments, the syringe assembly 22 in the retracted position may be located slightly proximal or distal to the syringe assembly in the storage position. In the illustrated embodiment, the retraction mechanism includes a spring 66, a syringe carrier 68, and a rotating member 70 that acts as a follower. In still other embodiments, the device 20 may not include a retraction mechanism 26 such that the syringe assembly remains unrestrictedly in its injection position until the syringe assembly is manually removed or repositioned by the user after the drug has been dispensed.

[0023] The plunger 44 may include an outrigger (not shown) that unlocks the rotating member 70 as the plunger 44 approaches the end of its proximal movement. The rotating member 70 is rotatably fixed to the lower shuttle member 64 by engagement between a latch and a latch recess of the lower shuttle member 64. The outrigger unlocks the member 70 by depressing the latch. The spring 66 has a torsional preload applied thereto and has one end engaged with the member 70 and an opposite end engaged with the shuttle assembly 60. When the latch is depressed, the spring 66 rotates the member 70.

[0024] The member 70 is rotatable within the housing 38 but is not axially movable relative to the housing 38. Other embodiments may also include an axially movable member 70. Rotation of the member 70 functions as a delay mechanism that prevents the retraction mechanism 26 from retracting the syringe assembly 22 until the syringe assembly has delivered its dose of medicament. The rotational speed of the member 70 can be adjusted by adjusting the viscosity of the grease disposed on or around the surface of the member 70 that contacts the housing 38, with a more viscous grease resulting in a slower rotation and a less viscous grease resulting in a faster rotation. The radial flange of the rotating member 70 may engage an overhang within the housing member 38 to limit proximal movement of the member 70. The spring 66 exerts an axial force, a torsional force, or both forces proximally on the member 70 to bias the member 70 proximally, thereby maintaining the member 70 in an axial position where the radial flange of the member 70 engages the internal overhang of the housing member 38.

[0025] The shuttle assembly 60 may include axially extending channels or ribs that engage corresponding features on the housing member 38 that allow the shuttle assembly 60 to move axially within the housing 38 but prevent relative rotation of the shuttle assembly 60 with respect to the housing member 38. The shuttle assembly 60 is biased distally by a spring 66 but is prevented from moving distally by the engagement of a latch (not shown) prior to activation of the drive mechanism 24. When the rotating member 70 completes its rotation, the aforementioned latch is disengaged, thus allowing the shuttle assembly 60 to move distally under the biasing force of the spring 66.

[0026] When the shuttle assembly 60 moves distally, it transports the syringe assembly 22 distally and moves the syringe assembly 22 back to the stored position shown in FIG. 2. The spring 66 biases the retraction mechanism 26 distally, thereby maintaining the syringe assembly 22 in its retracted position after the injection event. Locking mechanisms, such as a detent on the shuttle assembly 60 and a recess on the housing 38 member, additionally provide a locking engagement to secure the syringe assembly 22 in the retracted position with the needle 34 disposed within the housing 38 after the injection event, thereby allowing the user to then dispose of or otherwise handle the device 20 in a safe manner.

[0027] Figures 1-3 depict and illustrate an exemplary drive mechanism 24 and an exemplary retraction mechanism 26, although other mechanisms may also be used to drive syringe assembly 22 from a stored position to an injection position and / or from the injection position to a retracted position. Such drive and / or retraction mechanisms may (but are not required to) include one or more springs or deformable components that store energy when held in a pre-trigger state and release the stored energy when triggered to drive the syringe assembly from a stored position to an injection position and / or from the injection position to a retracted position. Such mechanisms may (but are not required to) include mechanisms that use a chemical reaction or process to generate power, such as by generating a gas by mixing two or more reagents or by igniting a small amount of flammable or explosive material. Such chemically driven mechanisms may include one or more storage containers for chemical reagents, a trigger that pierces or opens the storage container to allow the reagents to mix and / or provides a spark or other ignition source to initiate a chemical reaction, and a movable piston or other component that moves in response to an increase in gas pressure generated by the resulting chemical reaction. Such mechanisms may (but are not required to) include mechanisms that use stored electrical power (e.g., in a battery) to operate an electric motor that drives and / or retracts the syringe assembly or trigger other physical or chemical mechanisms. Such mechanisms may (but are not required to) include hydraulic or pneumatic systems (e.g., tubes), gears, cables, pulleys, or other known components for transferring kinetic energy from one component to another. In some embodiments, rather than having separate mechanisms for driving and then retracting the syringe assembly, a single mechanism may be configured to perform both driving and then retracting the syringe assembly.

[0028] Figure 4 illustrates an exemplary arrangement of one or more main PCBs 82 within the end portion 39 according to a first set of embodiments of the device 20. The one or more main PCBs may be arranged orthogonal to the longitudinal axis 48, may be stacked on top of one another, and / or may be arranged side-by-side on the same plane orthogonal to the longitudinal axis 48. The main PCB defines an opening 83 configured such that, for example, when the end cap 36 is removed and the syringe needle 34 of the syringe assembly 22 is driven proximally during a dispensing event to inject a patient, the syringe needle 34 passes therethrough. As shown, the main PCB extends away from the longitudinal axis 48 by a radial distance 45 that is greater than the radial distance 41 of the user grippable portion 37. Figure 4 also shows one or more secondary PCBs 84 that are substantially orthogonal to the main PCB and extend parallel to the longitudinal axis 48, and the secondary PCBs may be communicatively coupled to the main PCB via one or more PCB connectors 114. The secondary PCB 84 may carry an additional sensing system, although such a secondary PCB is optional and may be excluded in certain embodiments to reduce manufacturing complexity and cost.

[0029] Figures 5A and 5B illustrate another embodiment of the main PCB 82 that is not coupled to any secondary PCBs. FIG. 5A shows a top perspective view of the main PCB 82 according to some embodiments of the device 20, while FIG. 5B shows a bottom perspective view of the same PCB 82. The main PCB 82 includes a top surface 82a (shown in FIG. 5A) and a bottom surface 82b (shown in FIG. 5B, and the top surface 82a and the bottom surface 82b are understood to be part of the PCB 82). The top surface 82a may include or support a power source 102, such as a coin cell battery that in some embodiments is mounted on a battery clip (only the battery clip is depicted in FIG. 5A). The power source 102 provides power to electrical components integrated or coupled to the injection device 20. A battery door (not shown) within the housing 38 can hinge or swing open to allow access to the power source 102. The main PCB 82 may also include a processing circuit 108. In some embodiments, the processing circuit 108 may take the form of a system-on-chip (SOC) integrated circuit that includes a processor, memory, and input / output ports. However, the processing circuit 108 may also be implemented using other types of components such as a microcontroller (MCU) or an application-specific integrated circuit (ASIC). The processing circuit 108 may be configured to execute computer-executable instructions stored on a non-transitory storage medium. The main PCB 82 may also include or be communicatively coupled to a plurality of different types of sensors, such as a base cap removal sensor 110, an accelerometer 112, a temperature sensor 125, and / or one or more capacitive pads 122 and 123.

[0030] The base cap removal sensor 110 enables the processing circuit 108 to detect whether the base cap 36 is attached to the housing 38 or has been removed by the user. The base cap removal sensor 110 may be communicatively or electrically coupled to the processing circuit 108.

[0031] The accelerometer 112 can also detect the shock or acceleration caused by the start of a dispensing event in which the syringe assembly 22 is driven by the drive mechanism 24 from the storage position to the injection position. The accelerometer 112 can also detect the shock or acceleration caused by the backward movement at the completion of a dispensing event in which the syringe assembly 22 is driven by the retraction mechanism 26 from the injection position to the retracted position. The accelerometer 112 can send an output signal to the processing circuit 108 via one or more electrical connections, enabling the processing circuit to analyze the output signal.

[0032] In some embodiments, the processing circuit 108 can analyze the signal output from the accelerometer 112 to determine a specific condition or state of the device 20, or detect the occurrence of a specific event or action. For example, the processing circuit 108 can distinguish when the base cap 36 is removed or when the activation button 52 is unlocked. The processing circuit 108 can also be configured to determine when a dispensing event has started or completed based on the signal from the accelerometer 112, either alone or in combination with signals from one or more skin contact sensors.

[0033] When a dispensing event is initiated, the drive mechanism 24 is actuated to drive the syringe assembly 22 from the storage position to the injection position. This driving motion provides one or more accelerations that can be detected by a signal output from the accelerometer 112. For example, the pressing force applied by the drive mechanism 24 when the drive mechanism 24 drives the syringe assembly 22 in the proximal direction from the storage position can cause the accelerometer 112 to detect an acceleration in the distal direction along the longitudinal axis 48. When the syringe assembly 22 hits its stop position at its injection position at the end of this driving motion, the sudden stop of the syringe assembly 22 can cause the accelerometer 112 to detect an acceleration in the proximal direction along the longitudinal axis 48. Either (or both) of this proximal or distal acceleration can cause the accelerometer 112 to output a first acceleration spike that can be detected by the processing circuit 108. This first acceleration spike can indicate the start of a dispensing event.

[0034] Similarly, when the dispensing event is completed, the retraction mechanism 26 is actuated to drive the syringe assembly 22 from the injection position to the retracted position. This driving motion imparts one or more accelerations, which can also be detected by a signal output from the accelerometer 112. For example, the pressing force applied by the retraction mechanism 26 when the retraction mechanism 26 drives the syringe assembly 22 in the distal direction from the injection position can cause the accelerometer 112 to detect a proximal acceleration along the longitudinal axis 48. When the syringe assembly reaches the retracted position, the sudden stop of the syringe assembly 22 can cause the accelerometer 112 to detect a distal acceleration along the longitudinal axis 48. Either (or both) of these proximal or distal accelerations can cause the accelerometer 112 to output a second acceleration spike that can be detected by the processing circuit 108. This second acceleration spike can indicate the completion of the dispensing event. As used herein, "acceleration spike" is defined as any artifact of an acceleration or vibration signal output by an accelerometer or vibration sensor (e.g., a piezoelectric sensor) that indicates the start and / or completion of a dispensing event.

[0035] Many types of medications need to be stored at a first relatively low temperature (e.g., 36 - 46°F or 2 - 8°C) to prevent degradation, but then need to be warmed to a second, higher temperature (e.g., room temperature, or 65 - 75°F or 18 - 24°C) before being injected into a patient. To ensure that the medication in barrel 30 is stored at the appropriate storage temperature and / or to ensure that the medication is warmed to the appropriate injection temperature, injection device 20 may include a mechanism for estimating the temperature of the medication. By ensuring that the medication has been warmed to the appropriate temperature, this information may be transmitted to a phone or the device itself may signal the patient that the device is ready for use. In some embodiments, this temperature measurement function may be performed by a temperature sensor 125 mounted directly on main PCB 182 to estimate the temperature of the medication. This temperature sensor may be communicatively or electrically coupled to processing circuit 108 and outputs a temperature output signal that is received and analyzed by the processing circuit. In one example, temperature sensor 125 is mounted on the distal surface of the PCB and, in some examples, is circumferentially spaced from pads 122, 123.

[0036] Temperature sensor 125 may include any of a plurality of types of temperature sensors that may be mounted on the PCB, including but not limited to a thermistor (e.g., a negative temperature coefficient (NTC) thermistor, or a resistance temperature detector (RTD)), a thermocouple, or a semiconductor-based temperature sensor. Temperature sensor 125 may be configured and positioned to measure the temperature of a thermal ballast. The thermal ballast may include all or a portion of the silicon substrate of main PCB 82 itself. Alternatively, the thermal ballast may include a suitable heat sink composed of other materials (e.g., a polymer) mounted on main PCB 82. The thermal ballast may be in contact with temperature sensor 125 or may surround all or a portion of it.

[0037] Near - field communication (NFC) or Bluetooth Low Energy (BLE) connectivity can be provided by one or more antennas 104 mounted on the PCB 82. Such an antenna 104 can receive a signal from a processing circuit 108 that causes the antenna to send wireless communication to an external device. FIG. 5A depicts only one antenna 104, but some embodiments may include two or more chip antennas, for example, one BLE antenna and a separate NFC antenna. In some embodiments, the processing circuit 108 may itself include an integrated BLE antenna, while the antenna 104 may include an NFC antenna. Some embodiments may also use chip antennas instead of the PCB trace antennas as depicted.

[0038] The main PCB may also be communicatively coupled or integrated with a plurality of sensors that detect contact with the skin tissue. The skin contact sensors can be used to verify proper contact with the user's skin before the user activates the injection device 20. The injection device 20 can also indicate to the user which sensors detect skin contact and which do not. Thereby, the user knows in which direction to tilt or move the injection device 20 before injection. This function reduces the likelihood of injection failure, where the needle 34 fails to penetrate the user's skin or penetrates at an inappropriately shallow angle.

[0039] FIG. 5B depicts an exemplary embodiment including two capacitive pads 122 and 123 for detecting skin contact. Pads 122, 123 are shown as separate planar structures disposed along the distal surface of the PCB. The capacitive pads 122 and 123 can be configured to detect the proximity of human tissue by measuring the effect of such tissue on the electric field formed by the sensor, e.g., the effect of such human tissue on the capacitance of the electrical circuit monitored or measured by the sensor. Since the capacitance sensor does not require metal electrical terminals that directly contact the skin tissue, it can be partially or completely encapsulated behind a protective non-conductive cover (e.g., made of plastic, etc.). This can increase the durability of the capacitance sensor by reducing the penetration of moisture or foreign objects into sensitive electrical components. The capacitance sensor can also reduce the risk of electrostatic discharge damaging sensitive electrical components within the device since the capacitance sensor does not require exposed metal contacts either. The capacitive pads 122 and 123 can each independently detect contact with the skin tissue, whereby the processing circuit 108 can determine when one pad has detected contact while the other has not. FIG. 5B depicts two capacitive pads 122 and 123, but other embodiments can have fewer or more capacitive pads. For example, the main PCB 82 can include only a single capacitive pad or can have three, four, five, six, or more capacitive pads.

[0040] Figure 6 provides a system architecture diagram of electrical components within device 20 and communication links with an exemplary external device 650, according to some embodiments of device 20. Some or all of these components may be mounted on the main PCB 82 depicted earlier in FIGS. 5A and 5B. As previously considered and depicted in the previously mentioned figures, these electrical components may include a processing circuit 108. In some embodiments, the processing circuit 108 may take the form of a Bluetooth Low Energy (BLE) system-on-chip (SOC). Such a BLE SOC may include a processing core 624 (e.g., a microprocessor or an arithmetic logic unit (ALU)), an on-board memory 626 (e.g., a non-transitory computer-readable medium such as volatile or non-volatile memory) used to store programming instructions executed by the processing core 624, and a chip including a BLE circuit 628 and a BLE antenna 630. In some embodiments, as previously considered, the BLE circuit 628 and the BLE antenna 630 may be replaced by or complemented with an NFC communication circuit and / or antenna. The processing circuit 108 is configured to control and regulate the functions of the electrical components depicted in FIG. 6. The processing circuit receives power from the power supply 102.

[0041] The processing circuit 108 may be communicatively coupled to a plurality of electrical components including a base cap removal sensor 110, an accelerometer 112, a temperature sensor 125, and / or one or more touch sensors 606.

[0042] The touch sensor 606 may take the form of capacitive pads 122 and 123, as previously depicted and described in FIG. 5B. However, the touch sensor 606 may take the form of any other type of sensor configured to detect contact with skin tissue, such as, for example, an electrical resistance sensor.

[0043] As described above, the accelerometer 112 can take the form of any circuit configured to detect impacts, vibrations, and / or accelerations associated with the start and / or completion of a dispensing event. For example, the accelerometer 112 can take the form of an accelerometer configured to detect acceleration along one, two, or three axes, or it can take the form of a piezoelectric vibration sensor.

[0044] The base cap sensor 110 can take the form of a physical, electrical, optical, and / or magnetic sensor that detects whether the base cap 36 is attached to the housing 38 or removed by the user. The temperature sensor 125 can comprise any of a plurality of types of temperature sensors that can be mounted on the PCB as described previously. The processing circuit 108 can also optionally be connected to a device 632 for providing user feedback that is integrated with the device 20. The means for user feedback can include, for example, one or more indicator lights implemented using light-emitting diodes (LEDs), a display, a tactile indicator such as a vibration motor, and / or an auditory indicator such as a speaker.

[0045] The processing circuit 108 can be communicatively coupled to each of the previously mentioned components via one or more physical, electrical channels. In some cases, the signals received by the processing circuit 108 can be converted from analog signals to digital signals using an analog-to-digital converter (ADC) (not shown).

[0046] The processing circuit 108 can be configured to enable the injection device 20 to communicate wirelessly with an external device (e.g., a mobile phone, a wearable device, a laptop, and / or a server database, etc.). For example, the BLE circuit 628 and the BLE antenna 104 can enable the processing circuit 108 to transmit wireless BLE advertising packets to the external device 650.

[0047] FIG. 6 also shows an exemplary external device 650 that is physically separate from the injection device 20. In this embodiment, the exemplary external device 650 can take the form of a mobile smartphone having a processor 652 (e.g., a microprocessor or CPU) and a storage device 658. The storage device 658 can include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by the processor 652, cause the device 650 to perform the operations described herein. These computer-executable instructions can include mobile applications such as medical mobile applications. The device 650 can further include a display 660 and a user input device 662. The user input device 662 can include physical buttons or switches integrated with the smartphone. Although shown separately in FIG. 6, all or a portion of the user input device 662 can be integrated with the display 660, for example, within a touch-sensitive screen.

[0048] The device 650 can be configured to establish a wireless communication link with the injection device 20. For example, the external device 650 can include a BLE circuit 656 coupled to a BLE antenna 657 that communicates with the processing circuit 108.

[0049] Further details of the design and operation of the exemplary drug delivery device 20 can be found in U.S. Patent Application Publication No. 2021 / 0093784 (A1) entitled “Status Sensing Systems Within an Injection Device Assembly,” the entire disclosure of which is incorporated herein by reference.

[0050] As described herein in connection with FIGS. 5A and 5B, the drug delivery device can be configured to generate data regarding the state of the device, or regarding the occurrence of a particular event or action. For example, the processing circuitry of the drug delivery device can analyze signals from an accelerometer to determine when an injection event started and / or completed. As another example, the processing circuitry can analyze signals from a skin contact sensor to verify proper contact with the user's skin prior to the start of an injection event. In some embodiments, the data can include information regarding the time of an injection event, the time elapsed since an injection event, the date of an injection event, the temperature of the drug stored within the drug delivery device, the state of a skin contact sensor, or any other suitable data, and aspects of the techniques described herein are not limited in this regard.

[0051] In some embodiments, the generated data is provided to a computing device (e.g., external device 650), such that the computing device can be used to monitor injection event activity and / or the state of the drug delivery device. For example, a mobile application on the computing device can be used to record data received from the drug delivery device (e.g., injection event information), such as the time and / or date of an injection event. In some embodiments, this can help the user adhere to an injection regimen, as injection event information is recorded automatically and accurately.

[0052] According to some embodiments, a drug delivery device may communicate with a computing device by broadcasting an advertising packet (e.g., a Bluetooth Low Energy (BLE) advertising packet) that includes injection event information. For example, when delivering a dose of a drug, the drug delivery device may initiate the broadcast of an advertising packet that includes the time and / or date of the injection event. In some embodiments, a mobile application on the computing device may automatically receive and log the injection event information. In some embodiments, as described herein, the use of such advertising packets may eliminate the need to pair devices that may be cumbersome for the user. For example, when two devices are communicating using Bluetooth, a part of the Bluetooth pairing process may require the user to perform multiple steps to complete the pairing process, which may be time-consuming and / or confusing for patients who are not computer-savvy.

[0053] However, due to the lack of a pairing process, advertising packets may be incorrectly (and unintentionally) received by different computing devices. For example, a patient may receive advertising packets on their mobile device from drug delivery devices belonging to different users. Automatically logging the injection event information contained in those advertising packets may interfere with the patient's injection regimen. Thus, rather than automatically logging injection event information upon receiving an advertising packet, a computing device may be configured to analyze (e.g., at the application level) context data associated with the received advertising packet according to the techniques described herein in order to avoid logging incorrect information. In some embodiments, the context data may be used to determine whether to automatically log injection event information or to prompt the user for additional information (e.g., to confirm whether to log injection event information when the received data may not be associated with the patient). In some embodiments, the context data may be used to determine whether to ignore a received advertising packet by taking no action, i.e., neither logging injection event information nor prompting the user for additional information.

[0054] Some of the examples provided in this specification refer to processing BLE advertising packets, but it should be understood that the techniques herein can be used to process any wireless packet without departing from the spirit of the techniques described herein. For example, other types of packets that can be processed according to the techniques described herein include packets from any suitable wireless or cellular communication protocol such as WiFi, Long Range (LoRa), NFC, Radio-Frequency Identification (RFID), Ultra-Wideband (UWB), Matter, Long Term Evolution CAT M1 (LTE-M), Narrowband-Internet of Things (NB-IoT), and 4G. Thus, such examples are provided for illustrative purposes only and are not intended to limit the techniques described herein.

[0055] Figure 7 is a flowchart showing an exemplary computerized method 700 for determining whether to log data included in an advertising packet received from a drug delivery device according to some embodiments. At step 702, a computing device receives, from a wireless communication interface of the drug delivery device, an advertising packet that includes injection event information generated by the drug delivery device. In some embodiments, the advertising packet is received by a program operating on a computing device such as a mobile application. In some embodiments, the injection event information may include information regarding when a dose of the drug was delivered to the user, such as the time of the injection event, the time elapsed since the injection event, and / or the date of the injection event. In some embodiments, the drug delivery device may include an embodiment of device 20 described in connection with FIGS. 1-6. For example, the wireless communication interface may include antenna 104 of device 20.

[0056] In step 704, the computing device analyzes context data associated with the advertising packet to determine verification data. In some embodiments, the context data may include information about the advertising packet, information about the reception of the advertising packet, and / or information about the drug delivery device that broadcasts the received advertising packet. In some embodiments, the context data may be analyzed to determine verification data or data indicating whether the advertising packet was erroneously received by the computing device. In some embodiments, this may include comparing the context data to a set of criteria to determine verification data.

[0057] In step 706, the computing device determines, based on the verification data, whether to (i) include the injection event information in the dosing log, (ii) prompt the user for additional information regarding the advertising packet, and / or (iii) ignore the advertising packet. In some embodiments, if the verification data indicates that the advertising packet was received correctly (e.g., the advertising packet was received from the correct drug delivery device), the injection event information may be included in the dosing log. In some embodiments, if the verification data indicates that the advertising packet may have been received incorrectly (e.g., the advertising packet was received from a different drug delivery device), the computing device may prompt the user for additional information. In some embodiments, this may include prompting the user to confirm whether to record the injection event information in the dosing log (e.g., using a notification on the display of the computing device). This may allow the user to easily add the injection event information to their dosing log while preventing incorrect injection event information from interfering with their injection regimen. In some embodiments, if the verification data indicates that the probability of the advertising packet being received incorrectly is high, the computing device may ignore the advertising packet by not including the injection event information in the dosing log and not prompting the user for additional information. In this scenario, ignoring the advertising packet may also include the computing device deleting the advertising packet from its memory and / or configuring itself to ignore future advertising packets from the drug delivery device that sent the advertising packet. In some embodiments, step 706 may consist of selecting only between two of the options of (i) (including the injection event information in the dosing log), (ii) (prompting the user for additional information regarding the advertising packet), and (iii) (ignoring the advertising packet) based on the verification data.For example, in some embodiments, step 706 may consist of selecting only between options (i) and (ii), only between options (i) and (iii), or only between options (ii) and (iii) based on the verification data.

[0058] FIG. 8 shows a diagram of an exemplary system for determining whether to (i) log data included in an advertising packet received from a drug delivery device, (ii) prompt the user for additional information, and / or (iii) ignore the advertising packet, according to some embodiments. As shown, computing device 650 receives advertising packet 804 from wireless communication interface 802 of drug delivery device 20. In some embodiments, advertising packet 804 may be broadcast from one or more antennas of wireless communication interface 802, such as antenna 104. In some embodiments, the advertising packet may include injection event information generated by drug delivery device 20, and the injection event information may include information regarding the time and / or date of the dose of drug delivered to the user.

[0059] In some embodiments, after receiving the advertising packet, computing device 650 may optionally issue a scan response 816. In some embodiments, the scan response may indicate to drug delivery device 804 that the advertising packet has been received by computing device 650. In some embodiments, scan response 816 may be configured to cause the drug device to perform one or more functions. For example, upon receiving scan response 816, drug delivery device 804 may power down.

[0060] According to some embodiments, the computing device 650 may analyze the context data 806 associated with the advertising packet to determine the verification data 808. As described herein, including with respect to FIG. 7, the context data 806 may include information about the advertising packet, information about the reception of the advertising packet, and / or information about the drug delivery device to which the advertising packet was broadcast. FIG. 8 shows an example of different types of context data. As shown, the context data includes the reception time of the advertising packet (item 820), the time period between the injection event and the reception of the advertising packet (item 830), the location of the computing device at the time of reception of the advertising packet (item 840), the intensity of the radio frequency (RF) signal of the advertising packet (item 850), an indicator from a remote database as to whether another computing device has already received the advertising packet from the drug delivery device (item 860), an identifier (ID) associated with the drug delivery device (item 870), information indicating additional advertising packets received by the computing device (item 880), the distance between the computing device and the drug delivery device (item 890), and / or any suitable combination of context data types (e.g., any combination of items 820, 830, 840, 850, 860, 870, 880, and 890, and / or other data not shown in FIG. 8). The provided list of examples of context data is a non-exhaustive list, and it should be understood that any suitable type of context data may be included as the aspects of the techniques described herein are not limited in this regard.

[0061] In some embodiments, the verification data 808 may provide an estimate of whether the advertising packet 804 was correctly (or incorrectly) received by the computing device 650. In some embodiments, analyzing the context data 806 may include comparing the context data to a specified criterion to determine the verification data 808. Examples of analyzing different types of context data are described herein, including those with respect to FIGS. 9-15. In some embodiments, one type of context data 806 may be used to determine the verification data 808. For example, the computing device 650 may compare the reception time (item 820) to a specified criterion (e.g., a threshold time) to determine the verification data 808. In other embodiments, a combination of types of context data 806 may be used to determine the verification data 808. For example, the computing device may compare the strength of the RF signal of the advertising packet (item 850) to a first criterion (e.g., a threshold strength) and compare the reception time (e.g., a threshold time) to a second criterion. Based on the combination, the computing device may determine the verification data 808.

[0062] According to some embodiments, determining the verification data 808 based on a combination of types of context data 806 may include comparing each type of context data to a criterion (e.g., a threshold) and combining the results using a logical algorithm. For example, the results may be combined using a fuzzy logic algorithm (e.g., weighted or unweighted) to determine whether the advertising packet is likely to have been received incorrectly by the computing device. In some embodiments, using a weighted algorithm to combine the results of the analysis allows each type of context data to be weighted with a different importance. For example, context data that may provide a more reliable estimate of whether the advertising packet was received incorrectly may be weighted with a greater importance than other types of context data.

[0063] According to some embodiments, based on the verification data 808, the computing device 650 may determine (i) whether to include injection event information in the dosing log 812, (ii) whether to prompt the user for additional information 810, and / or (iii) whether to ignore the advertising packet 814. In some embodiments, if the verification data indicates that the advertising packet 804 may have been received erroneously from the drug delivery device 20, the computing device 650 may prompt the user for additional information 810. For example, the computing device 650 may provide a notification on the display of the computing device 650 to prompt the user to confirm whether to include the injection event information in the dosing log. In some embodiments, if the verification data indicates that the probability that the advertising packet 804 was received erroneously from the drug delivery device 20 is high, the computing device 650 may ignore the advertising packet 814. In some embodiments, if the verification data 808 indicates that the advertising packet 804 may have been received correctly by the computing device 650, the computing device 650 may automatically include the injection event information in the dosing log 812. FIG. 8 depicts an embodiment in which the verification data is used to select between three action processes (i), (ii), and / or (iii), but it should be understood that in some embodiments, the verification data may be used to select between only two action processes, for example, any two of the options (i), (ii), and (iii).

[0064] FIGS. 9-16 are exemplary flowcharts for analyzing different types of context data to determine whether to include injection event information in the dosing log or to prompt the user for additional information, according to some embodiments.

[0065] Figure 9 is an exemplary flowchart for analyzing the time at which a computing device receives an advantaging packet, according to some embodiments. At step 902, the reception time (item 820) is analyzed to determine whether it is within a specified time range. In some embodiments, the specified time can be one or more times when the user typically takes their dose of medication. For example, the user may take a dose of medication before and after mealtimes. If the computing device receives an advantaging packet at a time close to when the user typically takes a dose of medication, this may indicate that the advantaging packet was correctly received by the computing device (e.g., verification data 808b). If the computing device receives an advantaging packet at a time that is atypical for the user to take a dose of medication, this may indicate that the advantaging packet was incorrectly received by the computing device (e.g., verification data 808a).

[0066] According to some embodiments, the specified time and / or time range can be pre-set by the user. For example, the user may indicate the time or time range when they typically take a dose of medication (e.g., by interacting with the user interface of the computing device). In some embodiments, the time or time range is automatically determined based on past injection times included in the dosing log. For example, a machine learning model can be trained using the data included in the dosing log. Based on the reception time (item 820), the trained machine learning model can automatically determine whether the advantaging packet is likely to have been correctly (or incorrectly) received.

[0067] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, whether to ignore the advertising packet 810, or whether to include the injection event information in the dosing log 812. As described herein, if the reception time (item 820) is not within the specified time range, the computing device determines that the advertising packet was received in error (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the reception time (item 820) is within the specified time range, the computing device determines that the advertising packet was received correctly (verification data 808b) and may include the injection event information in the dosing log 812.

[0068] In some embodiments, the flowchart depicted in FIG. 9 can be modified to allow the computing device to select among three action processes as well as two action processes. For example, if the reception time is within a first range of expected times, the computing device may determine that the packet was likely received correctly and include the dosing event information in the log. If the reception time is not within the first range of expected times but is within a second range of expected times (where the second range is wider than the first range), the computing device may determine that the packet was possibly received inaccurately and prompt the user for additional information. If the reception time is not within either the first or second range of expected times, the computing device may decide to ignore the advertising packet.

[0069] FIG. 10 is an exemplary flowchart for analyzing the time period between the time of an injection event and the time of receipt of an advertising packet. At step 1002, the time period (item 830) is analyzed to determine whether it is less than a specified threshold. In some embodiments, if a short time (e.g., less than the threshold) has elapsed since the injection event, it is likely that the computing device was near the drug delivery device during the injection event. This may indicate that the advertising packet was correctly received by the computing device (e.g., verification data 808b). In some embodiments, if a long time (e.g., greater than the threshold) has elapsed since the injection event, it is likely that the computing device was not near the drug delivery device during the injection event. This may indicate that the advertising packet was incorrectly received by a different user from the drug delivery device (e.g., verification data 808a). In some embodiments, the threshold may be longer than 2 minutes, 4 minutes, 6 minutes, 8 minutes, 10 minutes, 20 minutes, 40 minutes, or any time within the range of 2 to 40 minutes.

[0070] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, ignore the advertising packet 810, or include the injection event information in the dosing log 812. As described herein, if the time period (item 830) is greater than the threshold, the computing device determines that the advertising packet was incorrectly received (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the time period (item 830) is less than the threshold, the computing device determines that the advertising packet was correctly received (verification data 808b) and may include the injection event information in the dosing log 812.

[0071] In some embodiments, the flowchart depicted in FIG. 10 can also be modified to allow a computing device to select between not only two but also three action processes. For example, if a time period (item 830) is lower than a first threshold, the computing device may determine that it is likely that the packet was received correctly and include dosage event information in the log. If the reception time is between the first threshold and a second, higher threshold, the computing device may determine that the packet may have been received inaccurately and prompt the user for additional information. If the reception time is greater than the second threshold, the computing device may decide to ignore the advertising packet.

[0072] FIG. 11 is an exemplary flowchart for analyzing the location of a computing device upon receipt of an advertising packet, according to some embodiments. At step 1102, the location of the computing device (item 840) is analyzed to determine whether the computing device is within a specified distance of a specified location. In some embodiments, different locations may be associated with different population and / or housing densities (e.g., the population density of a location within a city is greater than the population density of a rural neighborhood). If the location of the computing device is associated with a low population density, it may be more likely that an advertising packet (e.g., verification data 808b) was received correctly by the computing device. Conversely, if the location of the computing device is associated with a high population density, it may be more likely that an advertising packet was received incorrectly (e.g., verification data 808a) by the computing device.

[0073] Additionally, or alternatively, in some embodiments, a user may take a dosage of a drug at one or more locations, typically at the user's home. If the location of the computing device is near a typical dosing location (e.g., within a specified distance of a specified location), the computing device may have correctly received the advertising packet (verification data 808b). If the location of the computing device is not near a typical dosing location (e.g., not within a specified distance of a specified location), the computing device may have incorrectly received the advertising packet (verification data 808a).

[0074] According to some embodiments, the specified location and / or the specified distance may be pre-set by the user. For example, the user may indicate (e.g., by interacting with the user interface of the computing device) one or more locations where the drug may typically be taken (e.g., using a drug delivery device). Further, they may indicate the distance (e.g., radius) from a location where the computing device is expected to be during an injection event. In some embodiments, the one or more locations and the distance from the one or more locations may be automatically determined by the system. In some embodiments, a machine learning model may be trained based on data regarding the location of the computing device at the time of past injection events. The trained machine learning model may then be used to determine whether the location of the computing device at the time of receipt of the advertising packing is within the range of a typical location of an injection event.

[0075] Based on the verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, whether to ignore the advertising packet 810, or whether to include the injection event information in the dosing log 812. As described herein, if the location of the computing device (item 840) is not within the specified distance of the specified location, the computing device determines that the advertising packet was received erroneously (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the location of the computing device (item 840) is less than a threshold, the computing device determines that the advertising packet was received correctly (verification data 808b) and may include the injection event information in the dosing log 812.

[0076] In some embodiments, the flowchart depicted in FIG. 11 may be modified to allow the computing device to select among three action processes as well as two action processes. For example, if the location of the computing device (item 840) is within a first threshold distance of the specified location, the computing device may determine that the packet was likely received correctly and include the dosage event information in the log. If the location of the computing device is not within the first threshold distance of the specified location but is within a second (higher) threshold distance of the specified location, the computing device may determine that the packet was likely received inaccurately and prompt the user for additional information. If the location of the computing device is not within the second threshold distance of the specified location, the computing device may decide to ignore the advertising packet.

[0077] FIG. 12 is an exemplary flowchart for analyzing the strength of an RF signal upon receipt of an advertising packet, according to some embodiments. At step 1202, the strength of the RF signal is analyzed to determine whether it is greater than a specified threshold. In some embodiments, a high RF signal (e.g., greater than the threshold) may indicate that the drug delivery device is in proximity to the computing device. This may suggest a high likelihood that the advertising packet was correctly received by the computing device (e.g., verification data 808b). If the RF signal is low (e.g., below the threshold), this may indicate that the drug delivery device is not in proximity to the computing device and may suggest that the advertising packet was incorrectly received by the computing device (e.g., verification data 808a).

[0078] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, ignore the advertising packet 810, or include the injection event information in the dosing log 812. As described herein, if the strength of the RF signal (item 850) is greater than the specified threshold, the computing device determines that the advertising packet was incorrectly received (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the strength of the RF signal (item 850) is greater than the specified threshold, the computing device determines that the advertising packet was correctly received (verification data 808b) and may include the injection event information in the dosing log 812.

[0079] In some embodiments, the flowchart depicted in FIG. 12 can be modified to allow a computing device to select between not only two but also three action processes. For example, if the strength of the RF signal (item 850) is greater than a first threshold signal strength, the computing device may determine that the packet is likely to have been received correctly and include dosage event information in the log. If the strength of the RF signal is less than the first threshold signal strength but greater than a second (lower) threshold signal strength, the computing device may determine that the packet may have been received inaccurately and prompt the user for additional information. If the RF signal strength is less than the second threshold signal strength, the computing device may decide to ignore the advertising packet.

[0080] FIG. 13 is an exemplary flowchart for analyzing a remote database record indicating whether another computing device has already received an advertising packet from a drug delivery device, according to some embodiments (item 860). In step 1302, the computing device transmits a unique device identifier to the remote database. In some embodiments, the device identifier is unique to the drug delivery device and is included in the advertising packet broadcast by the drug delivery device. When the computing device receives an advertising packet, it transmits the unique identifier included in the advertising packet to the remote database. In some embodiments, the remote database may be accessible via a WiFi network, a cellular network, and / or any other suitable means for accessing the remote database, and aspects of the techniques described herein are not limited in that regard. In some embodiments, the remote database may include data storing information regarding advertising packets received on other computing devices. For example, the database may indicate that computing device X has previously received an advertising packet from a drug delivery device associated with the unique identifier "Y".

[0081] In step 1304, the computing device receives from the remote database an indication as to whether the database has a record of another computing device that received the advertising packet containing the unique identifier included in the advertising packet received by the computing device. In some embodiments, in step 1306, if the database has a record of another computing device that received the packet, this may indicate that the injection event information has already been captured by another device and that the advertising packet was likely received erroneously by the computing device (e.g., verification data 808a). If the database does not have a record of another computing device that received the advertising packet, it is possible that the advertising packet was correctly received by the computing device (e.g., verification data 808b).

[0082] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, whether to ignore the advertising packet 810, or whether to include the injection event information in the dosing log 812. As described herein, if the database indicates that another computing device has already received an advertising packet containing the device ID, the computing device determines that the advertising packet was received in error (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the database indicates that another computing device has not yet received an advertising packet containing the ID, the computing device determines that the advertising packet was received correctly (verification data 808b) and may include the injection event information in the dosing log 812. In some embodiments, the computing device may then update a remote database to indicate that the computing device has received an advertising packet containing a unique identifier.

[0083] FIG. 14 is an exemplary flowchart for analyzing an identifier associated with a drug delivery device according to some embodiments. At step 1402, the identifier associated with the drug delivery device (item 870) is analyzed to determine whether it is the same as the identifier defined for the patient (e.g., the user of the computing device). In some embodiments, the advertising packet includes a unique identifier for the drug delivery device as described herein with reference to FIG. 13. In some embodiments, if the device ID included in the advertising packet received by the computing device matches the patient ID assigned or defined for the user of the computing device, this may indicate that the advertising packet was correctly received by the computing device (e.g., verification data 808b). If the device ID does not match the patient ID assigned to the user, this may indicate that the advertising packet was incorrectly received by the computing device (e.g., verification data 808a).

[0084] In some embodiments, the patient ID may be stored in a remote database. For example, a physician may update the remote database to assign a patient ID to a user of a computing device. The patient ID may match the device ID associated with a drug delivery device prescribed to the same user. In some embodiments, the computing device may send the device ID included in the advertising packet to the remote database. The computing device may then receive from the remote database an indication as to whether the device ID matches a patient ID assigned to the user and stored in the database. In some embodiments, the remote database may be accessible via a WiFi network, a cellular network, and / or by using any other suitable means for accessing the remote database, and aspects of the techniques described herein are not limited in that regard. In some embodiments, the computing device may then analyze the indication received from the remote database to determine verification data 808.

[0085] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, ignore advertising packet 810, or include injection event information in dosing log 812. As described herein, if the device ID (item 860) is not the same as the specified identifier (e.g., patient ID), the computing device determines that the advertising packet was received in error (verification data 808a) and may prompt the user for additional information or ignore advertising packet 810. Alternatively, if the device ID (item 806) is the same as the specified ID, the computing device determines that the advertising packet was received correctly (verification data 808b) and may include the injection event information in dosing log 812.

[0086] In some embodiments, a computing device may receive two or more advertising packets simultaneously or within a short period of time relative to each other. For example, a computing device may receive multiple advertising packets within a short period of time in a public restroom where multiple patients may be taking a single dose of medication. FIG. 15 is an exemplary flowchart for analyzing an additional advertising packet (e.g., advertising packet B) received by a computing device simultaneously with an advertising packet (e.g., advertising packet A) according to some embodiments. In step 1502, advertising packet B (item 880) may be analyzed to determine whether it was received from a computing device different from advertising packet A. In some embodiments, this may include analyzing an identifier included in advertising packet B and / or other data associated with advertising packet B. If it is determined that advertising packet B was not received from the same computing device as advertising packet A, this may indicate that one or both of the advertising packets were received erroneously by the computing device (e.g., verification data 808a). If it is determined that advertising packet B was received from the same computing device as advertising packet A, this may indicate that both advertising packets were received correctly by the computing device (e.g., verification data 808b).

[0087] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, or whether to ignore one or both of the advertising packets 810, or whether to include the injection event information in the dosing log 812. As described herein, if no additional advertising packets (item 880) are received from the same drug delivery device, the computing device determines that the advertising packet was received in error (verification data 808a) and may prompt the user for additional information or ignore one or both of the advertising packets 810. Alternatively, if additional advertising packets (item 870) are received from the same drug delivery device, the computing device determines that the advertising packet was received correctly (verification data 808b) and may include the injection event information in the dosing log 812.

[0088] Figure 16 is an exemplary flowchart for analyzing the distance between a computing device and a drug delivery device. In some embodiments, determining the distance between the devices may include determining the amount of time it takes for an advertising packet to travel between the two devices. In some embodiments, the travel time may additionally or alternatively be included as context data (e.g., context data 806). The distance between the two devices may be calculated based on the travel time and the speed of light through air. Such techniques can be used with various protocols. As an example, this technique may be applied when processing packets according to UWB, which may enable a relatively accurate calculation of distance based on the travel time of the advertising packet.

[0089] In step 1602, analyze the distance between the drug delivery device and the computing device to determine whether it is less than a specified threshold. In some embodiments, a short distance (e.g., less than the threshold) may indicate that the drug delivery device is in proximity to the computing device. This may suggest that the advertising packet is likely to be correctly received by the computing device (e.g., verification data 808b). If the distance is far (e.g., greater than the threshold), this may indicate that the drug delivery device is not in proximity to the computing device and may suggest that the advertising packet has been incorrectly received by the computing device (e.g., verification data 808a).

[0090] Based on verification data 808a and 808b, the computing device determines whether to prompt the user for additional information, whether to ignore the advertising packet 810, or whether to include the injection event information in the dosing log 812. As described herein, if the distance between the devices (item 890) is greater than or equal to the specified threshold, the computing device determines that the advertising packet has been incorrectly received (verification data 808a) and may prompt the user for additional information or ignore the advertising packet 810. Alternatively, if the distance between the devices (item 890) is less than the specified threshold, the computing device determines that the advertising packet has been correctly received (verification data 808b) and may include the injection event information in the dosing log 812.

[0091] In some embodiments, the flowchart depicted in FIG. 16 may be modified to enable a computing device to select among not only two action processes but also three action processes. For example, if the distance between devices (item 890) is less than a first threshold distance, the computing device may determine that it is likely that the packet was correctly received and include dosage event information in the log. If the distance between devices is greater than the first threshold distance and less than a second (larger) threshold distance, the computing device may determine that the packet may have been received inaccurately and prompt the user for additional information. If the distance between devices is greater than the second threshold distance, the computing device may decide to ignore the advertising packet.

[0092] The various methods or processes outlined herein may be encoded as software executable on one or more processors using any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and / or programming tools or scripting tools and may be compiled as executable machine language code or intermediate code to be executed on a virtual machine or a suitable framework.

[0093] In this regard, various inventive concepts may be embodied as one or more non-transitory computer-readable storage media (e.g., computer memory, one or more floppy disks, compact disks, optical disks, magnetic tapes, flash memory, circuit configurations in a field programmable gate array or other semiconductor device, etc.) encoded with one or more programs that, when executed on one or more computers or other processors, implement various embodiments of the present invention. The non-transitory computer-readable media or media may be removable, such that the one or more programs stored thereon may be loaded onto any computer resource for implementing various aspects of the present invention as discussed above.

[0094] The terms "program," "software," and / or "application" are used herein in their general sense and refer to any type of computer code or set of computer-executable instructions employed to program a computer or other processor to implement various aspects of the embodiments discussed above. Additionally, according to one aspect, it should be understood that one or more computer programs that, when executed, implement the methods of the present invention need not reside on a single computer or processor but may be distributed modularly among different computers or processors to implement various aspects of the present invention.

[0095] Computer-executable instructions can be in many forms, such as by one or more computers or other devices, like program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. Typically, the functions of program modules can be combined or distributed as desired in various embodiments.

[0096] Also, data structures can be stored on a non-transitory computer-readable storage medium in any suitable form. A data structure can have fields related through locations within that data structure. Such relationships can likewise be achieved by allocating storage areas to fields having locations within a non-transitory computer-readable medium that convey relationships between fields. However, any suitable mechanism can be used to establish relationships between information within fields of a data structure, including through the use of pointers, tags, or other mechanisms that establish relationships between data elements.

[0097] Various inventive concepts can be embodied in one or more ways, and examples are provided. The acts performed as part of the method can be ordered in any suitable manner. Thus, although illustrated in exemplary embodiments as sequential acts, embodiments can be constructed in which acts are performed in a different order than illustrated, including performing some acts simultaneously.

[0098] As used herein in the specification and claims of this patent, the indefinite articles "a" and "an" should be understood to mean "at least one" unless explicitly stated to the contrary. When used in the specification and claims of this document, the phrase "at least one" in relation to a list of one or more elements should be understood to mean at least one element selected from any one or more of the elements in the list of elements, and need not include at least one of each and every element specifically listed in the list of elements, nor does it exclude any combination of elements in the list of elements. This allows elements other than those specifically identified in the list of elements referred to by the phrase "at least one" to optionally exist, whether or not they are related to these specifically identified elements.

[0099] As used herein in the specification and claims, the phrase "and / or" shall be understood to mean "either or both" of the elements so joined, i.e., elements that may be present conjunctively in some cases and disjunctively in other cases. Multiple elements listed using "and / or" should be interpreted in the same fashion, i.e., "one or more" of the elements so joined. Other elements other than those specifically identified by the "and / or" clause may optionally be present, whether or not they are related to those specifically identified elements. Thus, by way of non-limiting example, a reference to "A and / or B" when used in conjunction with open-ended language such as "comprising" may, in one embodiment, refer to only A (optionally including elements other than B), in another embodiment, refer to only B (optionally including elements other than A), in yet another embodiment, refer to both A and B (optionally including other elements), and so on.

[0100] As used in this specification and the claims, "or" should be understood to have the same meaning as "and / or" as defined above. For example, when separating items in a list, "or" or "and / or" shall be construed as inclusive. That is, it shall be construed to include not only at least one of a plurality of elements or a list of elements, but also a plurality, and optionally, additional items not listed. Terms such as "only one of", "exactly one of", or "consisting of" when used in the claims, indicate that only the terms explicitly indicating the contrary refer to exactly one element of a plurality of elements or a list of elements. Generally, as used in this specification, the term "or" should be construed to indicate an exclusive alternative (i.e., "one or the other but not both") when followed by exclusive terms such as "either", "one of", "only one of", or "exactly one of". "Consisting essentially of" shall have its ordinary meaning as used in the field of patent law when used in the claims.

[0101] In the claims, the use of ordinal terms such as "first", "second", "third", etc. to modify elements of a claim does not, by itself, imply any priority, precedence, or order of one claim element over another claim element, or the temporal order in which acts of a method are performed. Such terms are used only as labels to distinguish one claim element having a particular name from another element having the same name (in the absence of the use of ordinal terms).

[0102] The terminology and vocabulary used in this specification are for illustrative purposes and should not be construed as limiting. The use of "including", "comprising", "having", "containing", "involving", and variations thereof means including the items listed thereafter and additional items.

[0103] Although some embodiments of the present invention have been described in detail, various modifications and improvements will readily occur to those skilled in the art. Such modifications and improvements are intended to be within the spirit and scope of the present invention. Accordingly, the foregoing description is merely illustrative and not intended to be limiting.

[0104] Various aspects are described in this disclosure, including but not limited to the following aspects. Aspect 1. A computerized method comprising receiving, from a wireless communication interface of a drug delivery device, an advertising packet including injection event information associated with an injection event generated by the drug delivery device, the drug delivery device comprising: (a) a reservoir configured to hold a drug, (b) an activation button for initiating injection of the drug, and (c) a processing circuit in communication with the wireless communication interface; analyzing context data associated with the advertising packet to determine verification data; and based on the verification data, selecting between performing any two or three of the following actions: (i) including the injection event information in a dosing log, (ii) prompting the user for additional information regarding the advertising packet, or (iii) ignoring the advertising packet. Aspect 2. The computerized method according to claim 1, wherein receiving the advertising packet includes receiving a Bluetooth Low Energy (BLE) advertising packet. Aspect 3. The computerized method according to claim 1 or 2, wherein the drug delivery device further comprises one or more skin contact sensors for detecting skin contact and an accelerometer configured to output a signal representing the sensed acceleration. Aspect 4. Analyzing context data associated with an advertising packet includes analyzing data associated with the reception time of the advertising packet, according to the computerized method of claim 1. Aspect 5. Selecting between performing any two or three of the actions includes determining whether the time of the injection event is within a specified range of at least one specified time, and including injection event information in the dosing log if it is determined that the time of the injection event is within the specified range of at least one specified time, according to the computerized method of claim 4. Aspect 6. The computerized method according to claim 5, wherein the at least one specified time is automatically determined based on past injection times associated with the user. Aspect 7. Analyzing context data associated with an advertising packet includes analyzing data associated with the time period between the time of the injection event and the reception time of the advertising packet, according to the computerized method of claim 1. Aspect 8. Selecting between performing any two or three of the actions includes determining whether the time period between the time of the injection event and the reception time of the advertising packet is less than a threshold, and including injection event information in the dosing log if it is determined that the time period between the time of the injection event and the reception time of the advertising packet is less than the threshold, according to the computerized method of claim 7. Aspect 9. Analyzing context data associated with an advertising packet includes analyzing data associated with the location of the computing device that received the advertising packet, according to the computerized method of claim 1. Aspect 10. Selecting between performing any two or three of the actions includes determining whether the location is within a specified distance of at least one specified location, and including injection event information in the dosing log when it is determined that the location is within the specified distance of at least one specified location, the computerized method of claim 9. Aspect 11. The computerized method of claim 10, wherein the at least one specified location is automatically determined based on past injection locations associated with the user. Aspect 12. Analyzing context data associated with an advertising packet includes analyzing data associated with the strength of a radio frequency (RF) signal associated with the advertising packet, the computerized method of claim 1. Aspect 13. Selecting between performing any two or three of the actions includes comparing the strength of the RF signal to a specified threshold, and including injection event information in the dosing log when it is determined that the strength of the RF signal exceeds the specified threshold, the computerized method of claim 12. Aspect 14. Analyzing context data associated with an advertising packet includes analyzing data associated with the distance between the drug delivery device and the computing device that received the advertising packet, the computerized method of claim 1. Aspect 15. Selecting between performing any two or three of the actions includes comparing the distance to a specified threshold, and including injection event information in the dosing log when it is determined that the distance is less than the specified threshold, the computerized method of claim 14. Aspect 16. The advertising packet includes a unique drug delivery device identifier, and analyzing the context data associated with the advertising packet includes transmitting the unique drug delivery device identifier to a remote database and, in response to the transmission, receiving an indication of whether the remote database has a record of another computing device that received the advertising packet including the unique drug delivery device identifier. The computerized method according to claim 1. Aspect 17. Selecting between performing any two or three of the actions includes, based on the received indication, determining whether the remote database has a record of another computing device that received the advertising packet including the unique drug delivery device identifier, and if it is determined that the remote database has no record, including the injection event information in the dosing log. The computerized method according to claim 16. Aspect 18. Analyzing the context data associated with the advertising packet includes analyzing data indicating an identifier associated with the drug delivery device. The computerized method according to claim 1. Aspect 19. Selecting between performing any two or three of the actions includes determining whether the identifier associated with the drug delivery device is uniquely associated with the expected user of the drug delivery device by a healthcare provider and is the same as the specified identifier, and if it is determined that the identifier is the same as the specified identifier, including the injection event information in the regular dosing log. The computerized method according to claim 18. Aspect 20. Analyzing the context data associated with the advertising packet includes analyzing data related to additional advertising packets received by at least one processor. The computerized method according to claim 1. Aspect 21. Selecting between performing any two or three of the actions includes determining whether an additional advertising packet has been received from a second drug delivery device different from the drug delivery device, and if it is determined that the additional advertising packet has not been received from the second drug delivery device, including injection event information in the dosing log. The computerized method according to claim 20. Aspect 22. Analyzing context data associated with an advertising packet includes analyzing two or more of: (a) data associated with the reception time of the advertising packet, (b) data associated with the time period between the time of the injection event and the reception time of the advertising packet, (c) data associated with the location of the computing device that received the advertising packet, (d) data associated with the strength of the radio frequency (RF) signal associated with the advertising packet, (e) data associated with the distance between the drug delivery device and the computing device, (f) data indicating whether a remote database has a record of another computing device that received an advertising packet containing a unique drug delivery device identifier, (g) data indicating an identifier associated with the drug delivery device, and (h) data associated with an additional advertising packet. The computerized method according to claim 1. Aspect 23. The computerized method according to any one of claims 1 to 22, further including issuing a scan response after receiving the advertising packet. Aspect 24. The scan response is configured to turn off the drug delivery device. The computerized method according to any one of claims 1 to 23. Aspect 25. Prompting the user for additional information includes prompting the user to confirm whether injection event information should be included in the dosing log. The computerized method according to any one of claims 1 to 24. Aspect 26. Determining whether to include injection event information in the dosing log, whether to prompt the user for additional information, or whether to ignore advertising packets essentially consists of choosing between implementing only two of (i), (ii), and (iii). A computerized method according to any one of claims 1 to 25. Aspect 27. The injection event information includes the date and / or time of the injection event. A computerized method according to any one of claims 1 to 26. A non-transitory computer-readable medium including instructions that, when executed by one or more processors on a computing device, are operable to cause the one or more processors to perform the method according to any one of claims 1 to 27. A system comprising a memory storing instructions and a processor configured to execute the instructions to perform the method according to any one of claims 1 to 27.

Claims

1. A computerized method, wherein a computing device receives, from a wireless communication interface of a drug delivery device, an advertising packet containing injection event information generated by the drug delivery device, the injection event information including information regarding the delivery of a drug in an injection event, the drug delivery device comprising (a) a reservoir configured to hold the drug, (b) an activation button for initiating injection of the drug, and (c) a processing circuit communicating with the wireless communication interface, the receiving; analyzes context data associated with the advertising packet to determine verification data, the context data including information regarding the advertising packet, information regarding the reception of the advertising packet, and / or information regarding the drug delivery device that transmitted the advertising packet, the analyzing; selects to perform one of any combination of two or more of the following actions: (i) including the injection event information in a dosing log, (ii) prompting the user for additional information regarding the advertising packet, or (iii) ignoring the advertising packet, based on the verification data, the computerized method comprising.

2. The computerized method of claim 1, wherein receiving the advertising packet includes receiving a Bluetooth® Low Energy (BLE) advertising packet.

3. The drug delivery device further comprises one or more skin contact sensors for detecting skin contact, and an accelerometer configured to output a signal representing the sensed acceleration, the computerized method of claim 1.

4. The computerized method of claim 1, wherein analyzing the context data associated with the advertising packet includes analyzing data indicating the reception time of the advertising packet.

5. Selecting to perform one of any combination of two or more of the actions includes determining whether the time of the injection event is within a specified range of at least one specified time, When it is determined that the time of the injection event is within the specified range of the at least one specified time, including including the injection event information in the dosing log, the computerized method according to claim 4.

6. The computerized method according to claim 5, wherein the at least one specified time is automatically determined based on past injection times associated with the user.

7. Analyzing the context data associated with the advertising packet includes analyzing data indicating a time period between the time of the injection event and the reception time of the advertising packet, the computerized method according to claim 1.

8. Selecting to perform one of any two or more combinations of the actions includes determining whether the time period between the time of the injection event and the reception time of the advertising packet is less than a threshold; When it is determined that the time period between the time of the injection event and the reception time of the advertising packet is less than the threshold, including including the injection event information in the dosing log, the computerized method according to claim 7.

9. Analyzing the context data associated with the advertising packet includes analyzing data indicating the location of the computing device that received the advertising packet, the computerized method according to claim 1.

10. Selecting to perform one of any two or more combinations of the actions includes determining whether the location is within a specified distance of at least one specified location; When it is determined that the location is within the specified distance of the at least one specified location, including including the injection event information in the dosing log, the computerized method according to claim 9.

11. The computerized method according to claim 10, wherein the at least one specified location is automatically determined based on past injection locations associated with the user.

12. Analyzing the context data associated with the advertising packet includes analyzing data indicating the intensity of the radio frequency (RF) signal of the advertising packet, the computerized method according to claim 1.

13. Selecting to perform one of any two or more combinations of the actions is comparing the intensity of the RF signal with a specified threshold value; including the injection event information in the dosing log when it is determined that the intensity of the RF signal exceeds the specified threshold value, the computerized method according to claim 12.

14. Analyzing the context data associated with the advertising packet includes analyzing data indicating the distance between the drug delivery device and the computing device that received the advertising packet, the computerized method according to claim 1.

15. Selecting to perform one of any two or more combinations of the actions is comparing the distance with a specified threshold value; including the injection event information in the dosing log when it is determined that the distance is less than the specified threshold value, the computerized method according to claim 14.

16. The advertising packet includes a unique drug delivery device identifier, analyzing the context data associated with the advertising packet includes transmitting the unique drug delivery device identifier to a remote database; receiving, in response to the transmission, an indication of whether the remote database has a record of another computing device that received an advertising packet including the unique drug delivery device identifier, the computerized method according to claim 1.

17. Selecting to perform one of any two or more combinations of the actions is determining, based on the received indication, whether the remote database has the record of another computing device that received an advertising packet including the unique drug delivery device identifier; If it is determined that the remote database does not have the record, including including the injection event information in the dosing log, the computerized method according to claim 16.

18. Analyzing the context data associated with the advertising packet includes analyzing data indicating an identifier associated with the drug delivery device, the computerized method according to claim 1.

19. Selecting to perform one of any two or more combinations of the actions includes determining whether the identifier associated with the drug delivery device is uniquely associated with the expected user of the drug delivery device by a healthcare provider and is the same as a specified identifier; If it is determined that the identifier is the same as the specified identifier, including including the injection event information in the dosing log, the computerized method according to claim 18.

20. Analyzing the context data associated with the advertising packet includes analyzing data related to an additional advertising packet received by at least one processor, the computerized method according to claim 1.

21. Selecting to perform one of any two or more combinations of the actions includes determining whether the additional advertising packet was received from a second drug delivery device different from the drug delivery device; If it is determined that the additional advertising packet was not received from the second drug delivery device, including including the injection event information in the dosing log, the computerized method according to claim 20.

22. Analyzing the context data associated with the advertising packet includes analyzing two or more of: (a) data indicating the reception time of the advertising packet; (b) data indicating the time period between the time of the injection event and the reception time of the advertising packet; (c) data indicating the location of the computing device that received the advertising packet; (d) data indicating the strength of the radio frequency (RF) signal of the advertising packet; (e) data indicating the distance between the drug delivery device and the computing device; (f) data indicating whether a remote database has a record of another computing device that received an advertising packet including a unique drug delivery device identifier; (g) data indicating an identifier associated with the drug delivery device; and (h) data indicating additional advertising packets. The computerized method of claim 1.

23. The computerized method of claim 1, further comprising issuing a scan response after receiving the advertising packet.

24. The computerized method of claim 23, wherein the scan response is configured to turn off the drug delivery device.

25. Prompting the user for the additional information includes prompting the user to confirm whether to include the injection event information in the dosing log. The computerized method of claim 1.

26. Determining whether to (i) include the injection event information in the dosing log, (ii) prompt the user for the additional information, or (iii) ignore the advertising packet essentially consists of selecting to perform one of only two combinations of (i), (ii), and (iii). The computerized method of claim 1.

27. The injection event information includes the date and / or time of the injection event. The computerized method of claim 1.

28. A non-transitory computer-readable medium containing instructions, wherein when the instructions are executed by one or more processors on a computing device, the one or more processors are operable to cause the method according to any one of claims 1 to 27 to be executed.

29. A system comprising a memory storing instructions and a processor configured to execute the instructions to implement the method according to any one of claims 1 to 27.

Images