Drug delivery device with electronics and power management

A system may limit the number of times an inhalation device transmits inhalation data to a single time to reduce the battery usage of the inhalation device. The system may include an inhalation device that has medicament and an electronics module. The system may limit the number of times the inhalation device transmits new inhalation data to any mobile device to a single time by causing the server to receive the new inhalation data from one of the mobile devices and causing the server to transmit the new inhalation data to other of the mobile devices prior to the other mobile devices transmitting a request for the new inhalation data to the inhalation device. The inhalation device may include a Quick Response (QR) code, and a mobile application may determine at least one of a medication type or a number of doses of the inhalation device from the QR code.

BACKGROUND

Drug delivery devices facilitate the delivery of medication into a patient's body via various routes of administration. Typical routes of administration include oral, topical, sublingual inhalation, injection and the like. The devices may be used to deliver medications for the treatment of various diseases, ailments and medical conditions. Inhalation devices, for example, may be used to treat asthma, chronic obstructive pulmonary disease (COPD) and cystic fibrosis (CF). While drug delivery devices may be designed to deliver an appropriate dose of medication to a patient as part of a therapeutic treatment, the effectiveness of the treatment may be influenced by non-physiological factors, such as the patient's adherence and compliance in using the device.

Drug delivery devices may be equipped with sensors to track adherence and compliance. For example, a device may include a sensor for detecting when the device was actuated to deliver a dose of medication and/or its orientation during actuation. This information may be stored in a local memory and subsequently communicated to another device, such as a smartphone, tablet or computer, for further processing. The device's actuation history may be compared to a dosing regimen prescribed by a physician to determine the patient's level of adherence. Other sensor data, such as the device's orientation during operation, may be reviewed to determine whether the patient is using the device in a compliant manner that facilitates proper delivery of the medication.

To support the addition of sensors and communication mechanisms, a drug delivery device may include a local power source. If the drug delivery device is portable, the local power source may be portable as well. For example, the local power source may be a small battery. Certain factors, such as size, weight, and/or cost, may limit the types of viable power sources for the device. Accordingly, a finite amount of power may be available when choosing a power source for a drug delivery device with electrical components.

SUMMARY

A system may be configured to limit the number of times an inhalation device (e.g., an inhaler) transmits inhalation data to a single instance to, for example, help reduce the battery usage of the inhalation device. The system may include one or more inhalation devices. The inhalation device may include a mouthpiece, medicament, and an electronics module. The medicament may include albuterol (such as albuterol sulfate, for example, at a concentration of 117 mcg), fluticasone (such as fluticasone propionate, for example 55 mcg, 113 mcg, or 232 mcg of fluticasone propionate per dose delivered by the inhalation device), beclomethasone dipropionate, or fluticasone (such as fluticasone propionate, for example 55 mcg, 113 mcg, or 232 mcg of fluticasone propionate per dose delivered by the inhalation device) combined with salmeterol (such as salmeterol xinafoate, for example, 14 mcg of salmeterol xinafoate per dose delivered by the inhalation device). The electronics module may include any combination of a controller (e.g., processor), a communication circuit (e.g., transmitter, receiver, transceiver, etc.), one or more sensors (e.g., a pressure sensor, a temperature sensor, a humidity sensor, an orientation sensor, etc.), a power supply, and/or memory. The system may also include a cloud-based system (e.g., a remote server, such as a database) that includes a connection (e.g., wire connection) to a public or private network to facilitate communication between the cloud-based system and one or more external devices (e.g., computers, tablets, mobile devices, etc.).

The system may also include a plurality of mobile devices, where each mobile device may include a communication circuit, memory, and a mobile application for the inhalation device (e.g., a mobile application that is specific to the inhalation device). The mobile devices (e.g., and respective mobile applications) may, for example, be controlled by different family members or health care providers, for example, to ensure that the user of the inhalation device is adherent and compliant with their medication schedule.

In some examples, a first mobile application that resides on a first mobile device may be configured to cause the first mobile device to transmit a request for inhalation data to the inhalation device, receive the inhalation data from the inhalation device (e.g., which may include a timestamp or counter value determined by the inhalation device), and transmit the inhalation data to the cloud-based system. In some examples, the request for the inhalation data may include an indication of the most recent inhalation data of the inhalation device that is stored on the first mobile device. Accordingly, the inhalation data received by the first mobile application from the inhalation device in response to the request may come before (e.g., postdate) the indication (e.g., the request) that was sent to the inhalation device. For example, the inhalation data may have occurred after (be subsequent to) any inhalation data that may already be stored on the first mobile device. For instance, the indication may include a timestamp of the most recent inhalation data of the inhalation device that is stored on the first mobile device, and the inhalation data sent in response to the request may be inhalation data that postdates the timestamp of the most recent inhalation data (e.g., only inhalation data that postdates the timestamp).

A second mobile application that resides on a different mobile device may be configured to cause the second mobile device to transmit a request to the cloud-based system, and configured to receive the inhalation data of the inhalation device from the cloud-based system in response to the request. The second mobile application may be configured to transmit the request to the cloud-based system prior to the second mobile device transmitting a request for the inhalation data to the inhalation device, thereby ensuring that the battery usage of the inhalation device is reduced. In some examples, the request may include an indication of a last synchronization time between the second mobile application and the inhaler. As such, the cloud-based system may be configured to send inhalation data that is subsequent to the last synchronization time between the second mobile application and the inhaler. In some examples, the second mobile application is configured to cause the second mobile device to transmit the request to the cloud-based system in response to detecting a user login event to the second mobile application, which is prior to the second mobile device transmitting the request for the inhalation data to the inhalation device.

In some embodiments, the first and second mobile application may be authenticated (e.g., associated with the inhalation device) by the cloud-based system prior to receiving the inhalation data from the inhalation device and/or prior to transmitting the inhalation data to or receiving the inhalation data from the cloud-based system. For example, the second mobile application may be configured to cause the second mobile device to transmit a product identification (ID) associated with the inhalation device or a patient ID associated with a patient of the inhalation device to the cloud-based system prior to the second mobile application receiving the inhalation data of the inhalation device from the cloud-based system. The mobile application may receive the product ID via a Quick Response (QR) code located on the inhalation device.

For instance, the system may include an inhalation device and one or more mobile applications. The system may be configured to authenticate the mobile applications (e.g., associate the mobile applications/mobile devices with the inhalation device), and be configured to confirm that the inhalation device is properly marked (e.g., confirm that the medication marked on the inhalation device is correct). The inhalation device may include medicament, an electronics module, and a QR code. The mobile application may reside on a mobile device that comprises a camera. The mobile application may be configured to determine information relating to the inhalation device (e.g., a medication type and/or a number of doses of the inhalation device) using the QR code. For example, the mobile application may be configured to access the camera to receive information related to the QR code, determine a product identifier (ID) of the inhalation device based on the QR code, and determine information relating to at least one of a medication type or a number of doses of the inhalation device based on the product ID. For example, the product ID may be a multiple character code that directly indicates the type of medication, the strength of the medication, and/or the number of doses in the inhalation device. Alternatively or additionally, the mobile application may send the product ID to the cloud-based system, and the cloud-based system may send the information relating to the inhalation device to the mobile application.

The mobile application may also be configured to determine a dosing schedule and/or one or more dosage reminders based on the QR code. For example, the mobile application may be configured to determine the dosing schedule of the inhalation device and/or the timing of dose reminders directly from the QR code (e.g., via a product ID). Alternatively or additionally, the mobile application may receive the dosing schedule and/or timing of dose reminders from the cloud-based system using on the product ID. The mobile application may be configured to provide one or more dosage reminders based on the dosing schedule.

In examples where the inhalation device includes the QR code, the inhalation device does not include an actuator, button, or switch to initiate a communication pairing process with the mobile device. Rather, the mobile application is configured to pair the mobile device (e.g., a communication module of the mobile device) to the inhalation device (e.g., the communication module of the inhalation device) using the QR code. For example, the mobile application may be configured to determine a communication passkey that is unique to the inhalation device based on the QR code, and cause the mobile device to transmit the communication passkey to the electronics module of the inhalation device to enable communication between the electronics module and the mobile application. The communication passkey may include the product ID. The communication passkey may, for example, include a Bluetooth Low Energy (BLE) passkey.

The mobile application may be configured to determine that the inhalation device is not compatible with the mobile application based on the medication type of the inhalation device, and display an error message based on the inhalation device being not compatible with the mobile application. Further, the mobile application may be configured to reject the pairing process of the inhalation device with the mobile device based on the inhalation device being not compatible with the mobile application.

DETAILED DESCRIPTION

The present disclosure describes devices, systems and methods for sensing, tracking and/or processing usage conditions and parameters associated with a drug delivery device. The devices, systems and methods are described in the context of a breath-actuated inhalation device for delivering medication into a user's lungs. However, the described solutions are equally applicable to other drug delivery devices, such as an injector, a metered-dose inhaler, a nebulizer, a transdermal patch, or an implantable.

Asthma and COPD are chronic inflammatory disease of the airways. They are both characterized by variable and recurring symptoms of airflow obstruction and bronchospasm. The symptoms include episodes of wheezing, coughing, chest tightness and shortness of breath. The symptoms are managed by avoiding triggers and by the use of medicaments, particularly inhaled medicaments. The medicaments include inhaled corticosteroids (ICSs) and bronchodilators.

Inhaled corticosteroids (ICSs) are steroid hormones used in the long-term control of respiratory disorders. They function by reducing the airway inflammation. Examples include budesonide, beclomethasone (dipropionate/dipropionate HFA), fluticasone (propionate), mometasone (furoate), ciclesonide and dexamethasone (sodium). Parentheses indicate examples (e.g., preferred) salt or ester forms.

Different classes of bronchodilators target different receptors in the airways. Two commonly used classes are β2-agonists and anticholinergics. β2-Adrenergic agonists (or “132-agonists”) act upon the β2-adrenoceptors which induces smooth muscle relaxation, resulting in dilation of the bronchial passages. They tend to be categorised by duration of action. Examples of long-acting β2-agonists (LABAs) include formoterol (fumarate), salmeterol (xinafoate), indacaterol (maleate), bambuterol (hydrochloride), clenbuterol (hydrochloride), olodaterol (hydrochloride), carmoterol (hydrochloride), tulobuterol (hydrochloride) and vilanterol (triphenylacetate). Examples of short-acting β2-agonists (SABA) are albuterol (sulfate) and terbutaline (sulfate).

Typically short-acting bronchodilators provide a rapid relief from acute bronchoconstriction (and are often called “rescue” or “reliever” medicines), whereas long-acting bronchodilators help control and prevent longer-term symptoms. However, some rapid-onset long-acting bronchodilators may be used as rescue medicines, such as formoterol (fumarate). Thus, a rescue medicine provides relief from acute bronchoconstriction. The rescue medicine is taken as-needed/prn (pro re nata). The rescue medicine may also be in the form of a combination product, e.g. ICS-formoterol (fumarate), typically budesonide-formoterol (fumarate) or beclomethasone (dipropionate)-formoterol (fumarate). Thus, the rescue medicine is preferably a SABA or a rapid-acting LABA, more preferably albuterol (sulfate) or formoterol (fumarate), and most preferably albuterol (sulfate).

A number of approaches have been taken in preparing and formulating these medicaments for delivery by inhalation, such as via a dry powder inhaler (DPI), a pressurized metered dose inhaler (pMDI) or a nebulizer.

According to the GINA (Global Initiative for Asthma) Guidelines, a step-wise approach can be taken to the treatment of asthma. At step 1, which represents a mild form of asthma, the patient is given an as needed SABA, such as albuterol sulfate. The patient may also be given an as-needed low-dose ICS-formoterol, or a low-dose ICS whenever the SABA is taken. At step 2, a regular low-dose ICS is given alongside the SABA, or an as-needed low-dose ICS-formoterol. At step 3, a LABA is added. At step 4, the doses are increased and at step 5, further add-on treatments are included such as an anticholinergic or a low-dose oral corticosteroid. Thus, the respective steps may be regarded as treatment regimens, which regimens are each configured according to the degree of acute severity of the respiratory disease.

COPD is a leading cause of death worldwide. It is a heterogeneous long-term disease comprising chronic bronchitis, emphysema and also involving the small airways. The pathological changes occurring in patients with COPD are predominantly localized to the airways, lung parenchyma and pulmonary vasculature. Phenotypically, these changes reduce the healthy ability of the lungs to absorb and expel gases.

Bronchitis is characterized by long-term inflammation of the bronchi. Common symptoms may include wheezing, shortness of breath, cough and expectoration of sputum, all of which are highly uncomfortable and detrimental to the patient's quality of life. Emphysema is also related to long-term bronchial inflammation, wherein the inflammatory response results in a breakdown of lung tissue and progressive narrowing of the airways. In time, the lung tissue loses its natural elasticity and becomes enlarged. As such, the efficacy with which gases are exchanged is reduced and respired air is often trapped within the lung. This results in localised hypoxia, and reduces the volume of oxygen being delivered into the patient's bloodstream, per inhalation. Patients therefore experience shortness of breath and instances of breathing difficulty.

Patients living with COPD experience a variety, if not all, of these symptoms on a daily basis. Their severity will be determined by a range of factors but most commonly will be correlated to the progression of the disease. These symptoms, independent of their severity, are indicative of stable COPD and this disease state is maintained and managed through the administration of a variety drugs. The treatments are variable, but often include inhaled bronchodilators, anticholinergic agents, long-acting and short-acting β2-agonists and corticosteroids. The medicaments are often administered as a single therapy or as combination treatments.

Patients are categorized by the severity of their COPD using categories defined in the GOLD Guidelines (Global Initiative for Chronic Obstructive Lung Disease, Inc.). The categories are labelled A-D and the recommended first choice of treatment varies by category. Patient group A are recommended a short-acting muscarinic antagonist (SAMA) prn or a short-acting β2-aginist (SABA) prn. Patient group B are recommended a long-acting muscarinic antagonist (LAMA) or a long-acting β2-against (LABA). Patient group C are recommended an inhaled corticosteroid (ICS)+a LABA, or a LAMA. Patient group D are recommended an ICS+a LABA and/or a LAMA.

Patients suffering from respiratory diseases like asthma or COPD suffer from periodic exacerbations beyond the baseline day-to-day variations in their condition. An exacerbation is an acute worsening of respiratory symptoms that require additional therapy, i.e. a therapy going beyond their maintenance therapy.

For asthma, the additional therapy for a moderate exacerbation are repeated doses of SABA, oral corticosteroids and/or controlled flow oxygen (the latter of which requires hospitalization). A severe exacerbation adds an anticholinergic (typically ipratropium bromide), nebulized SABA or IV magnesium sulfate.

For COPD, the additional therapy for a moderate exacerbation are repeated doses of SABA, oral corticosteroids and/or antibiotics. A severe exacerbation adds controlled flow oxygen and/or respiratory support (both of which require hospitalization). An exacerbation within the meaning of the present disclosure includes both moderate and severe exacerbations.

FIG. 1is a front perspective view of an example inhalation device100. The example, inhalation device100may be a breath-actuated inhalation device. The inhalation device100may include a top cap102, a main housing104, a mouthpiece106, a mouthpiece cover108, medicament, and an air vent125. The top cap102may be mechanically attached to the main housing104. The mouthpiece cover108may be hinged to the main housing104so that it may open and close to expose the mouthpiece106. Although illustrated as a hinged connection, the mouthpiece cover108may be connected to the inhalation device100through other types of connections.

The inhalation device100may include a rescue medicament or a maintenance medicament. The rescue medicament may be a SABA or a rapid-onset LABA, such as formoterol (fumarate). The rescue medicament may also be in the form of a combination product, e.g. ICS-formoterol (fumarate), typically budesonide-formoterol (fumarate) or beclomethasone (dipropionate)-formoterol (fumarate). Such an approach is termed “MART” (maintenance and rescue therapy). In some examples, the medicament is albuterol (sulfate), fluticasone (propionate or furoate), or salmeterol (xinafoate) combined with fluticasone (propionate or furoate).

FIG. 2is a cross-sectional interior perspective view of the inhalation device100. Inside the main housing104, the inhalation device100may include a medication reservoir and a dose delivery mechanism/system. For example, the inhalation device may include a medication reservoir110(e.g., a hopper), a bellows112, a bellows spring114, a yoke118, a dose counter111, a transparent window147, a dosing cup116, a dosing chamber117, a deagglomerator121and a flow pathway119. The medication reservoir110may include medication, such as dry powder mediation, which may be delivered to the user via the mouthpiece106. The yoke118may be mechanically coupled (e.g., directly or indirectly) with the mouthpiece cover108such that a movement of the mouthpiece cover108may result in a movement of the yoke118. For example, when the mouthpiece cover108is moved to expose the mouthpiece106(e.g., from a closed position to an open position), the yoke118may move vertically (e.g., towards or away from the top cap102) within the inhalation device100.

The movement of the yoke118may cause the bellows112to compress, thereby delivering a dose of medication from the medication reservoir110to the dosing cup116. Thereafter, a user may inhale through the mouthpiece106to receive the dose of medication. The airflow generated from the user's inhalation may cause the deagglomerator121to aerosolize the dose of medication by breaking down the agglomerates of the medication in the dose cup116. The deagglomerator121may be configured to (e.g., fully) aerosolize the medication when the airflow through the flow pathway119meets or exceeds a rate or is within a specific range. When aerosolized, the dose of medication may travel from the dosing cup116, into the dosing chamber117, through the flow pathway119, and out of the mouthpiece106to the user. If the airflow through the flow pathway119does not meet or exceed a rate, or is not within a specific range, all or a portion of the medication may remain in the dosing cup116. In the event that the medication in the dosing cup116has not been aerosolized by the deagglomerator121, another dose of medication may not be delivered from the medication reservoir110when the mouthpiece cover108is subsequently opened. Thus, at least a portion of a dose of medication may remain in the dosing cup116until the dose has been aerosolized by the deagglomerator121.

As the user inhales through the mouthpiece106, air may enter the air vent125to provide a flow of air for delivery of the medication to the user. The flow pathway119may extend from the dosing chamber117to the end of the mouthpiece106. The flow pathway may include the dosing chamber117and the internal portions of the mouthpiece106. The dosing cup116may reside within or adjacent to the dosing chamber117.

Although illustrated as a combination of the bellows112, the bellows spring114, the yoke118, the dosing cup116, the dosing chamber117, and the deagglomerator121, the dose delivery mechanism may include a subset of the components described and/or the inhalation device100may include a different dose delivery mechanism (e.g., based on the type of inhalation device, the type of medication, etc.). For instance, in some examples the medication may be included in a blister strip and the dose delivery mechanism (e.g., one or more wheels, levers, and/or actuators) may be configured to advance the blister strip, open a new blister that includes a dose of medication, and make that dose of medication available to a dosing chamber and/or mouthpiece for inhalation by the user.

In the illustrated example dose delivery mechanism ofFIG. 1, the dose counter111may be mechanically coupled (e.g., directly or indirectly) with the mouthpiece cover108such that the dose counter111may increment or decrement when the mouthpiece cover108is opened or closed. The dose counter111may initially be set to a number of total doses available, which may be the number of doses in the medication reservoir110or the number of doses advertised by the manufacturer. As such, the dose counter111may be configured to decrease by one each time the mouthpiece cover108is moved from the closed position to the open position (or from the open position to the closed position), thereby indicating the remaining number of doses available. Alternatively, the dose counter111may initially be set to zero and may be configured to increase by one each time the mouthpiece cover108is moved from the closed position to the open position (or from the open position to the closed position), thereby indicating the total number of doses delivered from the medication reservoir110.

The inhalation device100may include an electronics module120, which may be housed within the top cap102. The electronics module120may include a printed circuit board (PCB) assembly122with one or more electrical components, such as a sensor system128and a wireless communication circuit129. The sensor system128may be configured to detect one or more parameters associated with the usage of the device and/or the environment in which the device is used or stored. The wireless communication circuit129may be configured to transmit the detected parameters to an external device, such as a smartphone, tablet, or computer, for further processing.

FIG. 3is an exploded perspective view of the example inhalation device100with the top cap102removed to expose the electronics module120. The top cap102may house the electronics module120, which may include a printed circuit board (PCB) assembly122. The PCB assembly122may include one or more components, such as a sensor system128and a wireless communication circuit129. The top cap102may be attached to the main housing104via one or more clips (not shown) that engage recesses on the main housing104. The top cap102may overlap a portion of the main housing104when connected, for example, such that a substantially pneumatic seal exists between the top cap102and the main housing104. The top surface of the main housing104may include one or more (e.g., two) orifices146. One of the orifices146may be configured to accept a slider140. For example, when the top cap102is attached to the main housing104, the slider140may protrude through the top surface of the main housing104via one of the orifices146. The top cap102may be removably attached to the main housing104. Alternatively or additionally, the electronics module120may be integrated within the main housing104and/or the top cap102housing the electronics module120may be permanently attached to the main housing104.

Further, in some examples, the electronics module120may reside in a separate device that is outside of and separate from the inhalation device100. For instance, the electronics module120may reside within an add-on device that is configured to be attached to and subsequently removed from the inhalation device100, for example, when the inhalation device100runs out of medication or expires. In such instances, the user may attached the add-on device that includes the electronics module120from one inhalation device100to another each time the user receives a new inhalation device100. The add-on device may be configured to be attached to any component of the inhalation device100, such as the main housing104, the mouthpiece, and/or a medication canister housed within the main housing of the main housing104of the inhalation device100(e.g., such that the sensors are in fluid communication with the mouthpiece and/or flow channel of inhalation device100. As such, in some examples, the inhalation device100may be replaced by an add-on device that includes the electronics module120(e.g. in whole or in part), and possibly an inhaler that does not include electronics.

FIG. 4is an exploded perspective view of the top cap102and the electronics module120. As shown inFIG. 4, the slider140may define an arm142, a stopper144, and a distal base145. The distal end145may be a bottom portion of the slider140. The distal end145of the slider140may be configured to abut the yoke118that resides within the main housing104. The top cap102may include a slider guide148that is configured to receive a slider spring146and the slider140. The slider spring146may reside within the slider guide148. The slider spring146may engage an inner surface of the top cap102, and the slider spring146may engage (e.g., abut) an upper portion (e.g., a proximate end) of the slider140. When the slider140is installed within the slider guide148, the slider spring146may be partially compressed between the top of the slider140and the inner surface of the top cap102. For example, the slider spring146may be configured such that the distal end145of the slider140remains in contact with the yoke118when the mouthpiece cover108is closed.

The distal end145of the slider145may also remain in contact with the yoke118while the mouthpiece cover108is opened or closed. The stopper144of the slider140may engage a stopper of the slider guide148, for example, such that the slider140is retained within the slider guide148through the opening and closing of the mouthpiece cover108, and vice versa. The stopper144and the slider guide148may be configured to limit the vertical (e.g., axial) travel of the slider140. This limit may be less than the vertical travel of the yoke118. Thus, as the mouthpiece cover108is moved to an open position, the yoke118may continue to move in a vertical direction towards the mouthpiece106but the stopper144may stop the vertical travel of the slider140such that the distal end145of the slider140may no longer be in contact with the yoke118.

As noted above, the electronics module120may include one or more components, such as the sensor system128and the wireless communication circuit129. The electronics module120may further include a switch130, a power supply126(e.g., a battery), a power supply holder124, an indicator (e.g., a light emitting diode (LED)), a controller (e.g., processor) and/or memory. When used herein, the terms controller and processor may be used interchangeably. One or more of the components of the electronics module120may be mounted on, and electrically coupled to, the PCB122. The controller and/or memory may be physically distinct components of the PCB122. Alternatively, the controller and memory may be part of a chipset mounted on the PCB122. For example, the wireless communication circuit129may include the controller and/or memory for the electronics module120. The controller of the electronics module120may include a microcontroller, a programmable logic device (PLD), a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any suitable processing device or control circuit. The memory may include computer-executable instructions that, when executed by the controller, cause the controller to implement the processes of the electronics module as described herein.

The controller may access information from, and store data in the memory. The memory may include any type of suitable memory, such as non-removable memory and/or removable memory. The non-removable memory may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The memory may be internal to the controller. The controller may also access data from, and store data in, memory that is not physically located within the electronics module120, such as on a server or a smartphone.

The battery126may provide power to the components of the PCB122. The battery126may be any suitable source for powering the electronics module120, such as a coin cell battery, for example. The battery126may be rechargeable or non-rechargeable. The battery126may be housed by the battery holder124. The battery holder124may be secured to the PCB122such that the battery126maintains continuous contact with the PCB122and/or is in electrical connection with the components of the PCB122. The battery126may have a battery capacity that may affect the life of the battery126. As will be further discussed below, the distribution of power from the battery126to the one or more components of the PCB122may be managed to ensure the battery126can power the electronics module120over the useful life of the inhalation device100and/or the medication contained therein.

The switch130may be actuated by the dose delivery mechanism of the inhalation device100. When incorporated using the example dose delivery mechanism described herein, the switch130may be actuated by a slider140as the mouthpiece cover108is moved from a closed position to an open position. Although it should be appreciated that if the inhalation device100includes a different dose delivery mechanism, then the switch130may be actuated by a different component of the dose deliver mechanism. When the switch130is actuated, the electronics module120may generate a signal causing the electronics module120to change states, such as from an off or sleep state to an active state. When in the active state, the controller of the electronics module120may wake and provide power to the sensor system128to enable the sensor system128to take measurement readings. Further, the electronics module120may store a dosing event (e.g., which may be referred to as a dose delivery event or an actuation event) each time the switch130is actuated. As described in more detail below, the electronics module120may have a plurality of power states, each with respective power consumption levels. For example, the electronics module120may be configured to operate in a system off state, a sleep state, and/or an active state, where the electronics module120consumes the least amount of power while in the off state (e.g., no power or just enough to run a clock), the sleep state uses more power than the off state (e.g., to drive the memory, the communication circuit, and/or a timer or clock), and the active state uses the most amount of power (e.g., to drive the controller, one or more sensors, the communication circuit, potentially in a faster advertising mode than the sleep state, and/or a timer or clock).

The sensor system128may include one or more sensors, such as one or more pressure sensors, temperature sensors, humidity sensors, orientation sensors, acoustic sensors, and/or optical sensors. The pressure sensor(s) may include a barometric pressure sensor (e.g., an atmospheric pressure sensor), a differential pressure sensor, an absolute pressure sensor, and/or the like. The sensors may employ microelectromechanical systems (MEMS) and/or nanoelectromechanical systems (NEMS) technology. The pressure sensor(s) may be configured to detect and/or measure pressure changes within the inhalation device100caused by an inhalation from (or an exhalation into) the mouthpiece106. One or more of the measured pressure changes may be used to determine the amount of airflow (e.g., an airflow rate) through the flow pathway119of the mouthpiece106. The magnitude of the airflow may indicate whether a user is properly using the device100. For example, if the deagglomerator121is configured to aerosolize a dose of medication when the airflow rate exceeds a threshold, a use may be deemed compliant if the determined airflow rate is above the threshold. Conversely, the use may be deemed non-compliant if the determined airflow is below the threshold.

The electronics module120(e.g., and/or a mobile application residing on an external device) may use measurements from the sensor system128to determine one or more dosing events. For example, the electronics module120may be configured to compare one or more measurements from the sensor system128to one or more threshold values to categorize an inhalation event as a no/low inhalation event, a fair inhalation event, a good inhalation event, an excessive inhalation event, and/or an exhalation event. For example, the electronics module may generate a good inhalation event when the measurements from the sensor system128indicate a flow rate in a particular range (e.g., between 200 liters per min (L/min) and 45 L/min), generate a fair inhalation event when the measurements from the sensor system128indicate a flow rate in another range (e.g., 30 L/min and 45 L/min), generate a no inhalation event when the measurements from the sensor system128indicate a flow rate that is less than a threshold value (e.g., 30 L/min), and an excessive inhalation event when the measurements from the sensor system128indicate a flow rate that is greater than an upper threshold (e.g., greater than 200 L/min).

The temperature sensor(s) may include a thermistor, a thermocouple, a resistance temperature detector, a temperature sensor chip and the like. The temperature sensor(s) may be configured to provide a temperature reading to the controller of the electronics module120and/or aggregated temperature readings over time. The temperature sensor(s) may be configured to measure the external temperature in the space proximate to the inhalation device100. Accordingly, main housing104and/or the top cap102may include an opening (e.g., a vent) to allow for the temperature sensor(s) to measure the ambient temperature external to the housing.

Alternatively or additionally, the temperature sensor(s) may be configured to measure temperature within the inhalation device100, such as within one or more of the top cap102, the main housing104, and/or the mouthpiece106of the inhalation device100. The ability to measure both internal and external temperature may allow the electronics module120to determine the operating temperature of the components of the electronics module120, the temperature of the air flowing through the inhalation device100when a user inhales through the inhalation device100, etc. Accordingly, the electronics module120may be configured to detect an over or under temperature condition, such as an over temperature condition of one or more of the components of the electronic module120(e.g., such as another sensor, like a pressure sensor), an over temperature condition of the inhalation device100, an ambient temperature that exceeds a threshold, etc. The electronics module120may be configured to cause the communication circuit129to transmit a temperature message to an external device (e.g., a mobile device) that indicates an over temperature condition, an ambient temperature reading, and/or a temperature reading of internal to the inhalation device100(e.g., such as a temperature change detected through the flow channel of the inhalation device100).

Further, in some examples, the pressure sensor may include a temperature sensor. The humidity sensor(s) may include a capacitive sensor, a resistive sensor, a thermal conductivity sensor and the like. The humidity sensor(s) may be configured to provide a humidity reading to the controller of the electronics module120and/or aggregated humidity readings over time. The temperature and/or humidity measurements may be used to identify and track the environmental conditions in which the inhalation device100is used or stored. The temperature and/or humidity measurements may be used to determine whether the device100is being operated or stored in an environment that could compromise the proper operation of the device100and/or the efficacy of the medication in the medication reservoir110. For example, extreme hot or cold temperatures, or excessive humidity levels, may contribute to device failures and/or alter the properties of the medication in the reservoir110.

The orientation sensor(s) may include an accelerometer, a gravity (G) sensor, a gyroscope, a magnetometer and the like. The orientation sensor(s) may be configured to provide an orientation reading (e.g., acceleration, rotation, direction, etc.) to the controller of the electronics module120and/or aggregated orientation readings over time. The data from the orientation sensor(s) may be used to identify and track how a user is handling or interacting with the device100when attempting to receive a dose of medication. The data may be used to determine whether the device100is being operated in a compliant manner, such as during dose delivery. For example, the orientation sensor(s) may indicate whether a user is holding the device100upside down during inhalation, which may prevent or impede the delivery of a full dose of medication from the dosing cup116and/or the dosing chamber117.

As noted above, the electronics module120may include one or more indicators, such as an LED, which may be housed or located on the device100such that any provided feedback may be observed by a user. The controller in the electronics module120may operate the indicators to provide feedback to users regarding their use of the inhalation device100and/or the conditions under which the inhalation device100is being used or stored. The controller may cause the status of the indicators to change (e.g., the LED may turn on, flash, change color, etc.) if one or more measurements from the sensor system128are above or below a predetermined threshold. For example, the controller may cause the LED may illuminate if the measured change in pressure, the determined airflow rate, the measured temperature and/or the measured humidity level exceeds the threshold. The controller may cause the LED may illuminate if the data from the orientation sensor(s) indicates that the device100is not being held properly.

The data from the sensor system128(e.g., pressure change, temperature, humidity level, etc.) and/or parameters derived therefrom (e.g., airflow rate) may be communicated to an external device, such as a smartphone, tablet or computer. More specifically, the wireless communication circuit129in the electronics module120may include a transmitter and/or receiver (e.g., a transceiver), as well as additional circuitry. For example, the wireless communication circuit129may include a Bluetooth chip set (e.g., a Bluetooth Low Energy chip set), a ZigBee chipset, a Thread chipset, etc. As such, the electronics module120may wirelessly provide data to the external device for review and/or additional processing. The external device may include software for processing the received information and for providing compliance and adherence feedback to users of the inhalation device100via a graphical user interface (GUI).

The power supply126may provide power to the electrical components of the PCB122. The power supply126may be any suitable source for powering the electronics module120, such as a coin cell battery, for example. The power supply126may be rechargeable or non-rechargeable. The power supply126may be housed by the power supply holder124. The power supply holder124may be secured to the PCB122such that the power supply126maintains continuous contact with the PCB122and/or is in electrical connection with the components of the PCB122.

The selection of the power supply126may be based various factors, such as its size, weight, cost and/or power capacity. Basing the selection of the power supply126on one attribute may negatively affect the operation or design of the inhalation device100with regard to other attributes of the power supply126. For example, a supply with the smallest physical dimensions, lowest weight, and/or lowest cost may have insufficient capacity to power the electronics module120for a desired period (e.g., the normal operating life of the device100). Conversely, a supply with sufficient capacity to power the electronics module120for the desired period may not fit within the space available in the top cap102and/or may be more expensive. Accordingly, the selection of the power supply126may include balancing one or more of its technical and/or commercial attributes. In addition, the operation of the electronics module120may be configured to limit or manage the power consumption from the power supply126, which may enable the selection of a smaller, less expensive supply that can reliably power the electronics module120for the desired period and under the desired operating conditions.

The electronics module120may have a plurality of power states, each with respective power consumption levels. For example, the electronics module120may be configured to operate in a system off state, a sleep state, and/or an active state. While the electronics module120is in the active state, the electronics module120may operate in one or more modes, such as a measurement mode, a data storage/data processing mode, an advertising mode, and/or a connected mode. It will be appreciated that the electronics module120may operate in multiple modes at one time (e.g., the modes may overlap).

In the measurement mode, the controller of the electronics module120may power on the sensor system128. The controller may cause the sensor system128to take pressure measurement readings, temperature readings, humidity readings, orientation readings, etc. for a predetermined period (e.g., up to 60 seconds) and/or until the mouthpiece cover108is closed or no changes in measurements are detected. The controller may turn off one or more components of the electronics module120while the sensor system128is capturing readings to further conserve power. The sensor system128may sample the readings at any suitable rate. For example, the sensor system128may have a sample rate of 100 Hz and thus a cycle time of 10 milliseconds. The sensor system128may generate a measurement complete interrupt after the measurement cycle is complete. The interrupt may wake the controller or cause it to turn on one or more components of the electronics module120. For example, after or while the sensor system128is sampling one or more pressure measurements, temperature readings, humidity readings, orientation readings, etc., the controller may process and/or store the data and, if measurements are complete, power off the sensor system128.

In the data storage/data processing mode, the controller may power on at least a portion of the memory within the electronics module120. The controller may process the readings from the sensor system128to compute, estimate, or otherwise parameters (e.g., usage and/or storage conditions) and store the parameters in memory. The controller may also compare the readings and/or parameters to one or more thresholds or ranges to assess how the inhalation device100is being used and/or the conditions under which the device100is being used. Depending on the results of the comparison, the controller may drive the indicators (e.g., an LED) to provide feedback to the user of the inhalation device100. As noted above, the electronics module120may operate in the measurement mode and the data storage/data processing mode simultaneously.

In the connected mode, the communication circuit and memory may be powered on and the electronics module120may be connected to or “paired” with an external device, such as a smartphone. The controller may retrieve data from the memory (e.g., sensor data and/or parameters derived from the sensor data) and wirelessly transmit the data to the external device. The controller may retrieve and transmit all of the data currently stored in the memory. The controller may also retrieve and transmit a portion of the data currently stored in the memory. For example, the controller may be able to determine which portions have already been transmitted to the external device and then transmit the portion(s) that have not been previously transmitted. Additionally or alternatively, the external device may request specific data from the controller, such as any data that has been collected by the electronics module120after a particular time or after the last transmission to the external device. The controller may retrieve the specific data, if any, from the memory and transmit the specific data to the external device.

Further, when connected with the external device, the electronics module120may be configured to transmit Bluetooth special interest group (SIG) characteristics for managing access to data stored in the module120. The Bluetooth SIG characteristics may include one or more of a manufacturer name of the inhalation device100, a serial number of the inhalation device100, a hardware revision number of the inhalation device100, and/or a software revision number of the inhalation device100. When connected with the external device, the electronics module120may retrieve data from memory and transmit the data to the external device.

The data stored in the memory of the electronics module120(e.g., the signals generated by the switch130, the measurement readings taken by the sensor system128and/or the parameters computed by the controller of the electronics module120) may be transmitted to an external device, which may process and/or analyze the data to determine the usage parameters associated with the inhalation device100. The data may include any a usage parameter (e.g., usage event), which for example, may include or indicate a use of the respective inhaler. In a relatively simple implementation, the at least one value may comprise “TRUE” when use of, for example an inhalation using, the respective inhaler has been determined, or “FALSE” when no such use of the respective inhaler is determined. However, the usage parameters may include any combination of the events described herein, such as, no inhalation events, low inhalations events, good inhalation events, excessive inhalation events, exhalation events, actuation events, error events, underuse events, overuse events, etc. Further, the usage parameters may include a count of the number of uses of the inhalation device100, a measure of airflow of inhalation device100, other measurements indicating the usage of the medicament of inhalation device100, such as the actuation of a switch configured to detect usage of inhalation device100(e.g., when the mouthpiece cover is moved from a closed position to an open position and/or a switch that is actuated upon the priming of the inhaler, such as to move and/or open a blister of medicament comprised within the inhaler), feedback from one or more sensors configured to detect use of inhalation device100, and/or the actuation of one or more buttons configured to be depressed upon use of inhalation device100.

Further, it should be appreciated that the electronics module (e.g., the processor)120is configured to timestamp the data (e.g., associate a timestamp with the data). For example, the electronics module120may include a local mean time clock, and may associate a timestamp that indicates the local mean time of the inhalation device100with the data determined by the inhalation device100. In other examples, the electronics module120may operate as an internal counter. When operating as an internal counter, the electronics module120determines a relative count (e.g., as opposed to providing a mean solar time, such as a local mean time), and associates the relative count with the determined data. For instance, the electronics module120may start an internal counter (e.g., which counts up from 0 indefinitely) when, for example, the electronics module120is woken out of an energy-saving sleep mode for the first time (e.g., after the mouthpiece cover is opened for the first time). Thereafter, any timestamp generated by the electronics module120may be a relative time (or count) based on the internal counter. The electronics module120may periodically update the system clock every 250 microseconds (μs).

Further, a software application residing on the external device may generate feedback for the user based on data received from the electronics module120. For example, the software application may generate daily, weekly, or monthly report, provide confirmation of error events or notifications, provide instructive feedback to the user, and/or the like.

FIG. 5is a diagram of an example system500including the inhalation device100, mobile devices502,504,506, a public and/or private network508(e.g., any combination of the Internet, a cloud network, and/or the like), and a computer (e.g., a server)512associated with a health care provider, such as a hospital or hospital system, a health system, a medical group, a physician, a clinic, and/or a pharmaceutical company. The system500also includes a digital health platform (DHP)510that resides on one or more servers, and may include computer software configured to perform the functions described in relation to the DHP510.

The mobile devices502,504,506may include a smart phone (e.g., an iPhone® smart phone, an Android® smart phone, or a Blackberry® smart phone), a personal computer, a laptop, a wireless-capable media device (e.g., MP3 player, gaming device, television, a media streaming devices (e.g., the Amazon Fire TV, Nexus Player, etc.), etc.), a tablet device (e.g., an iPad® hand-held computing device), a Wi-Fi or wireless-communication-capable television, a wearable device (e.g., the Apple Watch®), or any other suitable Internet-Protocol-enabled device. The mobile devices502,504,506may include a processor, memory, a communication circuit (e.g., a transceiver), speakers, microphone, and/or a display screen. The mobile devices502,504,506may have stored thereon a mobile application that is configured to cause the mobile device to perform the functions described herein, such as communicate with one or more inhalation devices100and/or the DHP510, receive, process, and/or aggregate the data received from the inhalers, generate new data and/or alerts based on the data received from the inhalers, and/or generate feedback (e.g., alerts), such as notifications, GUIs, or audio feedback, based on the inhaler data.

Also provided is a computer program comprising computer program code which is adapted, when the computer program is run on a computer, to implement any of the methods and technique described herein. In a preferred embodiment, the computer program takes the form of the mobile application, at least partially, for example the mobile application residing on a mobile device. And in some examples, the computer program is provided partially as the mobile application and partially as the DHP510. The embodiments described herein for the system500are applicable to the method and the computer program. Moreover, the embodiments described for the method and computer program are applicable to the system500.

Although described as mobile devices, the system500may, in some examples, include a stationary devices or a combination of mobile devices and stationary devices. The stationary devices include smart home interface devices, such as smart speakers, smart displays, smart home automation devices, and/or the like. The stationary devices include similar hardware and/or software as the mobile devices described herein (e.g., a processor, memory, a communication circuit (e.g., a transceiver), speakers, microphone, and/or a display screen), and therefore, are configured to perform the functions described herein with respect to the mobile devices.

The mobile devices502,504,506may be configured to communicate with the inhalation device100. The mobile devices502,504,506may also be configured to communicate with the public and/or private network508, which may be in communication with the DHP510and/or a computer associated with a health care provider512. For example, the mobile devices502,504,506may include communication circuit (e.g., a transceiver), and as such may be configured to transmit and/or receive RF signals via a Wi-Fi communication link, a Wi-MAX communications link, a Bluetooth® or Bluetooth Smart communications link, a near field communication (NFC) link, a cellular communications link, a television white space (TVWS) communication link, or any combination thereof. The mobile devices502,504,506may transfer data through the public and/or private network508to the DHP510using, for example, a dedicated API. For example, the mobile devices502,504,506may send usage data relating to one or more inhalation devices100to the DHP510.

As noted above, the inhalation device100may include the communication circuit129, such as a Bluetooth radio, for transferring data to an external device (e.g., one or more of the mobile devices502,504,506). The data may be referred to as usage data, usage parameters, and/or usage events. The data may include any of the data described herein, such as the signals generated by the switch130, the measurement readings taken by the sensor system128and/or parameters computed by the controller of the electronics module120. The data may include any combination of no inhalation events, low inhalations events, good inhalation events, excessive inhalation events, exhalation events, actuation events, error events, underuse events, overuse events, etc. The data may include a count of the number of uses of the inhalation device100, a measure of airflow of inhalation device100, other measurements indicating the usage of the medicament of inhalation device100, such as the actuation of a switch configured to detect usage of inhalation device100(e.g., when the mouthpiece cover is moved from a closed position to an open position and/or a switch that is actuated upon the priming of the inhaler, such as to move and/or open a blister of medicament comprised within the inhaler), feedback from one or more sensors configured to detect use of inhalation device100, and/or the actuation of one or more buttons configured to be depressed upon use of inhalation device100. The data may be associated with a timestamp, for example, as described herein.

The inhalation device100may receive data from the mobile devices502,504,506, such as, for example, program instructions, operating system changes, dosage information, alerts or notifications, acknowledgments, etc. Further, although illustrated as a single inhalation device100, the system500may include any number of inhalation devices100that are associated with a plurality of different users. It should be noted that some users will have multiple inhalation devices100that include the same medicament. For example, a user may have multiple inhalation devices100that include a rescue medicament (e.g., and keep them at different locations). Further, a user may have multiple inhalation devices100that include a particular maintenance medicament, such as when they are transitioning between refills. Further the system500is configurable with the inhalation devices100of a plurality of different users. As such, the system500is configured to communication, via respective mobile devices, with a plurality of different inhalers that are associated with a plurality of different users.

The mobile devices502,504,506may process and analyze the data to determine the usage parameters associated with the inhalation device100. For example, the mobile devices502,504,506may process the data to identify usage events, such as no inhalation events, low inhalations events, good inhalation events, excessive inhalation events, exhalation events, actuation events, error events, underuse events, overuse events, etc. The mobile devices502,504,506include a display device and software for visually presenting the usage parameters and/or data related to usage events through a GUI on the display device.

The mobile devices502,504,506may be configured to receive data (e.g., usage events) and associated timestamps (e.g., a relative count from an internal counter of the electronics module120) from the inhalation device100. The mobile devices502,504,506may determine a local mean time and a time zone for a timestamp, and associate the local mean time and time zone with the data (e.g., usage event). The mobile devices502,504,506may then send the data and the associated local mean time and time zone to the DHP. The DHP may associated the data, local mean time, and time zone with a user. Alternatively or additionally, the mobile devices502,504,506may associate the data, local mean time, and time zone with a user, and/or the DHP may determine the local mean time based on the timestamp received from the inhalation device100.

The DHP is configured to receive and aggregate inhaler data (e.g., usage events) from inhalers that are associated with a plurality of different users. In some examples, the DHP may reside on or across one or more servers, and may include computer software configured to perform the functions described in relation to the DHP. For example, the DHP may include a dashboard application that may be accessible by the computer512associated with a health care provider, such as a hospital or hospital system, a health system, a medical group, a physician, a clinic, and/or a pharmaceutical company. In some examples, the dashboard application is a web application (e.g., a web portal). For example, the DHP is also configured to provide data, such as inhaler data, to clinicians and physicians through the use of the dashboard application (e.g., via a REST API).

The DHP510is configured to receive and aggregate data from inhalation devices100, where the inhalers may be associated with a plurality of different users. For example, the DHP510is configured to receive and store inhaler data from the mobile devices502,504,506(e.g., the patient-facing mobile applications). The inhaler data may include any of the data described with reference to the inhalers described herein, such as usage events, error events, inhalation profiles, associated timestamps, medicament types, etc. The DHP510is configured to analyze and manipulate the data. For example, the DHP510may aggregate the data across of the inhalation devices that it receives data from, and then the DHP510may analyze the aggregated data, for example, to determine one or more metrics, provide feedback, etc. Further, the DHP510is also configured to provide data (e.g., or analytical information based on the data) to the user (e.g., via mobile devices502,504,506) or to the computer512associated with a health care provider (e.g., via the dashboard application). The inhaler data may include any of the data described with reference to the inhalers described herein.

The inhaler data may be associated with an inhalation device100and/or a user profile, for example, at the mobile devices502,504,506and/or at the DHP510. One user profile may be associated with multiple inhalation devices100of the same and/or different medicament types. The DHP510may also de-identify (e.g., disassociate) the inhaler data with a particular user profile, and the DHP510may perform analytics on de-identified data relating to the inhalation devices100. Although described as receiving the inhaler data from the mobile devices502,504,506, in some examples, the DHP510may receive the data directly from the inhalation devices100themselves, such as in instances where the communication circuits of the inhalation devices100include cellular chipsets that are capable of communicating directly with the DHP510.

Each time data is transferred from the inhalation device100to an external device, such as a one or more of the mobile devices502,504,506, the power supply126may provide power to one or more electrical components in the electronics module120, such as the communications circuit129. As such, the frequency of data transfers from the inhalation device100may affect overall power consumption and the ability of the power supply126to power the electronics module120for the desired period. That is, more frequent data transfers to an external device and/or data transfers to multiple external devices may increase the power requirements of the electronics module120and decrease the functional life of the power supply126. Accordingly, the system500may be configured to limit the number of times that the inhalation device100transmits new data to an external device (e.g., limit the transmission to a single data transfer). Further, in some examples, the inhalation device100may be prevented from transmitting data more than a limited number of times (e.g., more than once). After the data is transferred from the inhalation device100to an external device, the DHP510may be configured to receive the data from the mobile device, and transmit the data to the other authorized mobile device(s) associated with the user and the medicament within the system500. Further, in some examples, the mobile device (e.g., a mobile application residing on an external device) may check the system500(e.g., the DHP510) for information before requesting data from the inhalation device100, for example, to limit energy use of the inhalation device100. For instance, in some examples, when the mobile device and an inhalation device enter a connected mode, the mobile device may first request new data relating to the inhalation device100from the DHP510(e.g., as described herein) prior to requesting data from the inhalation device100. As such, the mobile device ensures that it has the most updated data that the inhalation device100has transmitted prior to requesting new data from the inhalation device100.

In one example, the inhalation device100may be provided to a child who is asthmatic. The child may have the mobile device502and the child's parents may have the mobile devices504,506. Each of the mobile devices502,504,506may include a mobile application that is configured to process and/or display data collected from the inhalation device100. The mobile applications on the mobile devices504,506may enable the child's parents to monitor the conditions or parameters associated with their child's use of the inhalation device100. The mobile application on the mobile device502may enable the child to do the same. As such, data from the inhalation device100may need to be transferred to three separate external devices.

If the data is transferred directly from the inhalation device100to the mobile devices502,504,506, the power consumption related to wireless transmissions may increase (e.g., increase three-fold) when compared to communicating with a single external device. This increase in power consumption may cause the functional life of the power supply126to be less than the expected life of the inhalation device100(e.g., less than the time during which the user is expected to receive doses of medication from the inhalation device100). Accordingly, to extend the life of the power supply126, one or more of the electronics module120, a mobile application residing on the mobile device504, and/or a DHP510may be configured to limit the number of times the data can be transferred from the electronics module120to an external device (e.g., limited to a single transfer of the data from the inhalation device100).

For example, referring again toFIG. 5, a child may be prescribed a medication that can be administered via the inhalation device100. The child's mother may download a mobile application on her mobile device, such as the mobile device504. The mobile application may enable the mobile device504to wirelessly connect with the inhalation device100and to receive data collected by the electronics module120. Such data may be indicative of when doses were delivered from the device100. The mobile application may also store the child's prescribed dosing regimen. As such, the mobile application may enable the child's mother to monitor when and how often her child is using the inhalation device100and whether her child is adhering to the dosing regimen. The child and the child's father may similarly download the mobile application for their respective mobile devices502,506. However, to extend the life of the power supply126of the electronics module120, the system500may be configured to limit the transfer of data from the electronics module120to a single transfer of the data (e.g., a transfer of the data to just one of the mobile devices502,504,506).

For example, in some embodiments, when a mobile device, such as the mobile device504, is within communication range of the electronics module120of the inhalation device100, the mobile device504(e.g., the mobile application residing thereon) may transmit a request for data from the inhalation device100. The request may include an indication of the most recent data that the mobile device504has stored (e.g., a timestamp of the most recent data from the inhalation device100that is stored on the mobile device504). If the inhalation device100has more recent data (e.g., data with a timestamp that is more recent than that indicated by the request), then the inhalation device100may transmit the more recent data to the mobile device504. Thereafter, the mobile device504that receives the more recent data may upload that data to the DHP510. Then, the other of the mobile devices that didn't receive the more recent data directly from the inhalation device100(e.g., such as the mobile devices502,506), may receive the more recent data from the DHP510, for example, as described below. For example, when a user logs into a mobile application on the other mobile devices, the mobile application may cause the mobile device to retrieve the data (e.g., all, recent data) from the DHP510, rather than from the inhalation device100. As such, the mobile applications on the other mobile devices may not request the data from the inhalation device100, because those mobile devices have already received the data from the DHP510.

Accordingly, the inhalation device100may be configured to limit the number of times it transfers the data to a mobile device (e.g., which may be any of the mobile devices, and which may be a different mobile device during each data transfer). In this example, the mobile device is limited to a single transfer of stored data, because, for example, once that data is provided to a single external device, the external device transfers the data to the DHP510, and the DHP510transfer the data to all other authorized external devices. If the mobile device was not limited to a single transfer of stored data, however, the same instance of stored data may be transferred to the DHP510multiple times, which may negatively affect the integrity and/or validity of the data in the DHP510(e.g., as multiple instances of the same data may exist in the DHP510).

More specifically, the DHP510may be configured to enable, and in some instances initiate, the transfer of data from the mobile devices502,504,506. For example, the DHP510may expose a REST API to the processors and/or mobile applications residing on the mobile devices502,504,506. The mobile devices502,504,506may send any data related to an inhalation device100that has not already been uploaded to the DHP510, and with this data send any combination of an indication of the associated user and/or the timestamp for the data (which may include the local time and time zone of the mobile devices). In some examples, the mobile devices502,504,506may be configured to send inhalation data (or an indication that there is no new inhalation data) to the DHP510periodically, such as every 15 minutes. The DHP510may also store incoming data from the computers512. The DHP510may receive the patient's consent via their respective mobile devices502,504,506.

The DHP510may transmit data, such as inhaler data, to one or more of the mobile devices502,504,506. For example, the DHP510may receive data from one mobile device, and then transmit that data to the other mobile device(s) associated with that user, for example, when the other mobile device(s) don't already have that inhaler data. In some examples, the mobile devices502,504,506may transmit a request to the DHP510(e.g., periodically, such as every 15 minutes) for all new inhaler data associated with a user. The request may include an indication of the user and at least one of an inhaler or a medicament type (e.g., a rescue medicament type or a maintenance medicament type). The request may also include an indication of the last synchronization time between that mobile device and the inhaler, regardless of whether any new inhaler related data was communicated from the inhaler to the mobile device. The last synchronization time for a mobile device may indicates the most recent time the inhaler was connected with that mobile device, regardless of whether any new inhaler related data was communicated from the inhaler to the mobile device. The DHP510may receive the request, determine the user, the inhaler, and/or the medicament type, and determine the last synchronization time between the mobile device and the inhaler. The DHP510may then determine whether it has stored any data (e.g., usage events) that postdate (come after) the synchronization time indicated by the request by comparing the associated timestamps with the last synchronization time provided in the request. If there is data for that inhaler that comes after the last synchronization time, the DHP510is configured to send the data and associated timestamps to the mobile device (e.g., with any combination of data that indicates the associated user, the inhaler, and/or medicament type). The data sent by the DHP510may include the data from the inhaler, such as a usage event, along with a timestamp of the data (e.g., including the local mean time and time zone of the event), inhaler information such as data indicating the medicament type and/or dosage, and data indicating the user associated with the event.

Further, in some examples, the DHP510may return additional data relating to the user and/or the medicament, such as profile information relating to the user, the prescription order information, user preferences, questionnaire responses, etc. For example, the request may include an additional field that indicates a last synchronization time between the mobile device and the inhalation device100or between the mobile device and the DHP510where information other than inhaler related data, such as usage events, was received by the mobile device. The DHP510may then determine whether it has stored any other data, such as that described above, that postdate the synchronization time indicated by the request, and if so, send the other data and associated timestamps (e.g., in combination with any combination of the associated user, the inhaler, and medicament type) to the mobile device.

As such, the system500may be configured to limit the number of times that an inhalation device100has to communicate its data to a mobile device, while also ensuring that multiple mobile devices502,504,506associated with the inhalation device100have the most recent data associated with the inhalation device100and/or the user, regardless of the number of mobile devices502,504,506associated with the inhalation device100and/or the user. This is particularly true in examples where the mobile device is configured to send new data received from the inhalation device100and/or an indication of a last synchronization between the mobile device and the inhalation device100to the DHP periodically, and also send requests to the DHP for new data not already stored on the mobile device periodically.

Further, the DHP510may cause the computer512associated with the health care provider to provide inhaler data to practitioners and health care professionals to allow them to view inhaler data specific to a program to which a patient has consented. In one example, the DHP510causes the computer512associated with the health care provider to provide the inhalation data via a graphical user interface (GUI) that is presented on a display device associated with the health care provider's computer.

The DHP510may define any number of programs, which in some instances may be configured and altered by a health care provider. When providing inhaler data to a health care provider, the DHP510may generate an alert (e.g., generate and provide a GUI) that is specific to a particular program associated with that health care provider. A program defines a set of criteria, such as types of medications (e.g., any combination of rescue and/or maintenance medications), specific patients and in turn their applicable inhalers, other users of the programs such as particular physicians, practice groups, and/or administrators, the types of data presented to the health care provider such as charts, event tables, usage summaries, etc. The health care provider may configure and establish any number of programs using the DHP510. Further, a particular patient and their inhalers may be associated with any number of unique programs. In some examples, the programs are stored and maintained by the DHP510, and the computer512associated with the health care provider is configured to access the data relevant to each program from the DHP510using, for example, an application, such as a dashboard or web application. In such examples, and once a program is established, the DHP510is configured to receive inhaler data associated with the program, analyze and manipulate the inhaler data to the extent necessary, and provide program data (e.g., via the dashboard) to the health care provider. The program data may include inhaler data that is specific to the configuration of a particular program, and for example, additional data that is derived from the inhaler data, as is described in more detail below. For example, the DHP510may enable a GUI, such as those described herein, on the computer512associated with the health care provider that presents the program data to the health care provider.

For example, the DHP510may include a dashboard application that may be accessible by the computer512associated with a health care provider. In some examples, the dashboard application is a web application (e.g., a web portal). For example, the DHP510is configured to provide data, such as inhaler data, to clinicians and physicians through the use of the dashboard application (e.g., via a REST API). The DHP510may cause the computer512associated with the health care provider to provide inhaler data to practitioners and health care professionals to allow them to view inhaler data specific to a program to which a patient has consented. In one example, the DHP510causes the computer512associated with the health care provider to provide the inhalation data via a graphical user interface (GUI) that is presented on the health care provider's computer.

Alternatively or additionally, in some examples, after the mobile device504receives the more recent data from the inhalation device100and uploads that data to the DHP510, the mobile application may be configured to cause the mobile device to transmit a notification to the inhalation device100indicating that the inhalation data was uploaded to the DHP510. Accordingly, upon receiving the notification that the inhalation data has been uploaded to the DHP510, the inhalation device100may be configured to not upload that data to another mobile application, even if it receives a request for that data. The mobile application may, however, be configured to transmit, to a mobile device, inhalation data that postdates the data that was uploaded to the DHP510.

Alternatively or additionally, in some examples, the system100may be configured such that the inhalation device100may only transfer data to one, single mobile device. For example, when the mobile application on the mobile device504(e.g., initially) connects to and/or receives data from the inhalation device100, the inhalation device100may receive and store an ID associated with the mobile device504. After receiving the ID, the inhalation device100may be restricted to connecting and transferring data to the mobile device504and/or to any other device with the same ID. If other external devices, such as the mobile devices502,506, attempt to connect to the inhalation device100, the inhalation device100does not transfer data if such devices have a different ID. Accordingly, the electronics module120may conserve power by limiting the instances in which it connects to external devices and transmits data collected by the sensor system128, for example.

All or a portion of the data transferred to the mobile device504may be communicated by the device504to a DHP510. The data may be stored in the DHP510where it may be later accessed or retrieved by the mobile application on the mobile device504and/or by a computer512associated with the health care provider. The data may also be accessed or retrieved by the respective mobile applications on the mobile devices502,506. Accordingly, the child and the child's father may still be able to monitor usage and/or other conditions associated with the inhalation device100on their respective mobile devices502,506even though the inhalation device100may be restricted to connecting with and/or transferring data to the mobile device504.

Further, in some examples, the inhalation device100may limit how often it communicates data with an external device (e.g., a mobile device), for example, when the inhalation device100is in connected mode. This may allow the inhalation device100to save battery power, for example, while in connected mode. The communication protocol enabled by the inhalation device100may, for example, include a parameter that defines how often the inhalation device100will accept requests for data while in connected mode. The parameter may, for instance, allow the inhalation device100to skip connection events without the external device dropping the connection, and as such, the inhalation device100may remain in connected mode even though it skips connections events. In such examples, the inhalation device100may set this parameter to its maximum value. For example, if the inhalation device100communicates using BLE, the inhalation device100may configure the parameter “connSlaveLatency” to a maximum value (e.g., every 2 seconds, every 4 seconds, etc.).

Further, in some examples, the inhalation device100does not include an actuator, button, or switch to initiate a pairing process with a mobile device. The inhalation device100may, however, include other means for facilitating the pairing process. For example, the inhalation device100may include a barcode, such as a Quick Response (QR) code160. Although described as a QR code, other types of barcodes may be used. The use of the QR code to initiate the pairing process may further reduce the required battery/power consumption of the electronics module120of the inhalation device100. Further, although the QR code160is illustrated as being located on the top of the top cap102of the inhalation device100, in other examples, the inhalation device100may include a QR code that is located elsewhere on the inhalation device100, such as on the main housing104or on the mouthpiece cover108. The mobile device may include a camera, and the mobile application residing on the mobile device may be configured to access the camera and read the QR code160.

The QR code160may include (e.g., be coded to indicate) various types of information associated with the inhalation device100. The QR code160may include a BLE passkey that is unique to the inhalation device100. Upon reading or scanning the QR code160using the camera, the mobile application may determine the BLE passkey associated with the device100and complete an authentication process, thereby enabling it to communicate with the electronics module120using the BLE passkey. If the communications session is subsequently lost because, for example, the inhalation device100moves out of range, the mobile device may be configured to use the BLE passkey to automatically pair with the electronics module120without using the QR code160when the inhalation device100is back within range.

Further, in some examples, the QR code160may include an indication of the type of the inhalation device100(e.g., the medication type, the number of doses, the strength, the dosing schedule, etc.). Table 1 provides a non-limiting example of the identifiers included in the QR code160for various inhalation devices100.

As shown in Table 1, the identifier further denotes the dose strength and the total dose count of the inhaler prior to use. The mobile application residing on the mobile device may use the information identifier by the identifier to, in combination with the usage information, control a user interface of the mobile device to issue a notification when the label recommended dosages have been exceeded, as previously described. Alternatively or additionally, the mobile application residing on the mobile device may use the total dose count of the inhaler prior to use and the usage information to determine the number of doses remaining in the respective inhalation device100.

The QR code160on the inhalation device100may, for instance, further comprise a security key, for example in the form of a series of alphanumerical characters, for preventing unauthorized users from accessing the respective inhalation device100. The mobile application residing on the mobile device may be able to decrypt the respective encrypted data once the mobile application has been provided with the security key, but may not be able to decrypt the respective encrypted data before the mobile application has been provided with the security key. More generally, the security key may be included in the respective identifier.

In a non-limiting example, the system is configured to restrict one or more, e.g. each, of the inhalers included in the system to a single user account.

In such an example, a passkey, e.g. provided in the QR code, may allow synchronization between the respective inhalation device100and mobile applications of the system. The passkey and, in turn, the usage parameter data, e.g. inhalation and/or usage data, from the respective inhalation device may be public. This public inhalation data may not be associated with the particular subject until synchronization with the single user account.

Since the system is configured to restrict the respective inhaler to being associated with the single user account, the respective inhaler may be prevented from being synchronized with another user account, for example in situations where the inhaler is lost or stolen. In this way, third parties may be prevented from acquiring usage parameter data which is not theirs.

Accordingly, the mobile application can determine the type of inhalation device100when receiving the QR code160(e.g., the medicament type, the dosage strength, and the number of doses), and prior to the first use of the inhalation device100by a user. For examples, the mobile application may receive (e.g., capture) an image of the QR code using the camera of the mobile device. The mobile application may then decode the image of the QR code to acquire the data stored within the QR code. In some examples, the QR code160may comprise a multi-digit alphanumeric code, such as a six digit code (e.g., ssm060, aaa200, etc.) that indicates the type of the inhalation device100. For example, the multi-digit alphanumeric code may be a unique drug product identifier (e.g., product ID) of the inhalation device100. Accordingly, the QR code160may directly communicate the type of the inhalation device100(e.g., the medication type, the number of doses, the strength, the dosing schedule, etc.) via the multi-digit alphanumeric code provided via the QR code160(e.g., and as such, the mobile application does not have to access a website using the QR code160to acquire the type of the inhalation device). A multi-digit alphanumeric code of “AAA030” may, for example, indicate that the medication type is albuterol, the strength is 117 mcg, and the number of doses is 30.

In some examples, the BLE passkey provided via the QR code160may comprise the multi-digit alphanumeric, for example. Further, in some embodiments, the QR code160may not directly indicate, to the mobile application, the information relating to the medication type, the number of doses, the strength, the dosing schedule, etc. of the inhalation device100. Rather, the QR code160may comprise information that can be used by the mobile application to acquire such information relating to the inhalation device100from a remote device (e.g., a cloud-based system, such as a remote server).

Moreover, in some examples, the QR code160may include any combination of a serial number of the inhalation device100, a hardware revision number of the inhalation device100, and/or a software revision number of the inhalation device100. Further, although described with reference to a QR code160, the inhalation device100may include any code (e.g., barcode) that indicates the type of the inhalation device100, a communication passkey (e.g., BLE passkey), a manufacturer name of the inhalation device100, a serial number of the inhalation device100, a hardware revision number of the inhalation device100, a software revision number of the inhalation device100, and/or the like.

Upon receiving the QR code160, the mobile application may determine the details of the inhalation device100(e.g., the medication type, the number of doses, the strength, the dosing schedule, etc.), such as directly through a multi-digit alphanumeric provided via the QR code160. Alternatively or additionally, in some example, the mobile application may be configured to send a request (e.g., that includes the multi-digit alphanumeric code) to a DHP510for the details relating to the inhalation device100(e.g., the medication type, the number of doses, the strength, the dosing schedule, etc.). This can be particular important, for example, in instances where mislabeling issues can arise, and the inhalation device100is mislabeled with the incorrect type of medication. The use of the QR code160allows for accurate details relating to the inhalation device100to be acquired by the mobile application prior to the user using the inhalation device100, for example. This may, for example, help prevent issues relating to incorrect dosage reminders based on incorrect dosing schedules, incorrect refill warning, etc. that could otherwise have been determined based on the incorrect medication labeling on the inhalation device100. Further, in some examples, the mobile application may determine that the user associated with the mobile application is not prescribed the medication and/or dose strength indicated by the QR code. For instance, the mobile application may send the medication type or the strength of the inhaler indicated by the QR code to the DHP510, and in response, may receive an indication of the user's compatibility with the medication type or the strength of the inhaler from the cloud-based server (e.g., such as a direct compatible or not compatible message, or an indication of the medication types and strengths associated with the user). For example, the mobile application may request and receive the user's prescription information from the DHP510. And the mobile application may generate an alert (e.g., a GUI displayed on the mobile device and/or at the computer associated with the HCP) that indicates that the user has the incorrect inhaler, either based on the medicament type or strength, as indicated by the QR code. Further, in such instances, the mobile application may reject the pairing process with the inhalation device100.

Further, in some examples, the mobile application may be used with specific types of inhalation devices, but not all. Accordingly, the mobile application may display an error message if the information provided by the QR code160indicates that that the inhalation device100is not an inhalation device that is compatible with the mobile application. Further, the mobile application may provide a link to a mobile application store to download the correct mobile application for the type of inhalation device100. If, for example, the mobile application determines that the inhalation device is not the compatible with the mobile application (e.g., based on the QR code160or multi-digit alphanumeric code), the mobile application may reject the pairing process of the inhalation device100with the mobile device (e.g., before data transfer or a first use of the inhalation device100). If the mobile application determines that the inhalation device is the compatible with the mobile application (e.g., based on the QR code160or multi-digit alphanumeric code), the mobile application may accept or allow the pairing process of the inhalation device100with the mobile device.

FIG. 6is a graph600of example airflow rates versus pressure. The airflow rates and profile shown inFIG. 6are merely examples and the determined rates may depend on the size, shape, and design of the inhalation device100and its components.

The electronics module120may generate data (e.g., usage events) by comparing signals received from the sensor system128and/or the determined airflow metrics to one or more thresholds or ranges, for example, as part of an assessment of how the inhalation device100is being used and/or whether the use is likely to result in the delivery of a full dose of medication. For example, where the determined airflow metric corresponds to an inhalation with an airflow rate below a particular threshold, the electronics module120may determine that there has been no inhalation or an insufficient inhalation from the mouthpiece106of the inhalation device100. If the determined airflow metric corresponds to an inhalation with an airflow rate above a particular threshold, the electronics module120may determine that there has been an excessive inhalation from the mouthpiece106. If the determined airflow metric corresponds to an inhalation with an airflow rate within a particular range, the electronics module120may determine that the inhalation is “good”, or likely to result in a full dose of medication being delivered. The electronics module120may associate a timestamp with the data.

The pressure measurement readings and/or the computed airflow metrics may be indicative of the quality or strength of inhalation from the inhalation device100. For example, when compared to a particular threshold or range of values, the readings and/or metrics may be used to categorize the inhalation as a certain type of event, such as a good inhalation event, a low inhalation event, a no inhalation event, or an excessive inhalation event. The categorization of the inhalation may be usage parameters stored as personalized data of the subject.

The no inhalation event may be associated with pressure measurement readings and/or airflow metrics below a particular threshold, such as an airflow rate less than or equal to 30 Lpm. The no inhalation event may occur when a subject does not inhale from the mouthpiece106after opening the mouthpiece cover108and during the measurement cycle. The no inhalation event may also occur when the subject's inspiratory effort is insufficient to ensure proper delivery of the medication via the flow pathway119, such as when the inspiratory effort generates insufficient airflow to activate the deagglomerator121and, thus, aerosolize the medication in the dosing cup116.

The low inhalation event may be associated with pressure measurement readings and/or airflow metrics within a particular range, such as an airflow rate greater than 30 Lpm and less than or equal to 45 Lpm. The low inhalation event may occur when the subject inhales from the mouthpiece106after opening the mouthpiece cover108and the subject's inspiratory effort causes at least a partial dose of the medication to be delivered via the flow pathway119. That is, the inhalation may be sufficient to activate the deagglomerator121such that at least a portion of the medication is aerosolized from the dosing cup116.

The good inhalation event may be associated with pressure measurement readings and/or airflow metrics above the low inhalation event, such as an airflow rate which is greater than 45 Lpm and less than or equal to 200 Lpm. The good inhalation event may occur when the subject inhales from the mouthpiece106after opening the mouthpiece cover108and the subject's inspiratory effort is sufficient to ensure proper delivery of the medication via the flow pathway119, such as when the inspiratory effort generates sufficient airflow to activate the deagglomerator121and aerosolize a full dose of medication in the dosing cup116.

The excessive inhalation event may be associated with pressure measurement readings and/or airflow metrics above the good inhalation event, such as an airflow rate above 200 Lpm. The excessive inhalation event may occur when the subject's inspiratory effort exceeds the normal operational parameters of the inhalation device100. The excessive inhalation event may also occur if the device100is not properly positioned or held during use, even if the subject's inspiratory effort is within a normal range. For example, the computed airflow rate may exceed 200 Lpm if the air vent is blocked or obstructed (e.g. by a finger or thumb) while the subject is inhaling from the mouthpiece106.

Any suitable thresholds or ranges may be used to categorize a particular event. Some or all of the events may be used. For example, the no inhalation event may be associated with an airflow rate which is less than or equal to 45 Lpm and the good inhalation event may be associated with an airflow rate which is greater than 45 Lpm and less than or equal to 200 Lpm. As such, the low inhalation event may not be used at all in some cases.

The pressure measurement readings and/or the computed airflow metrics may also be indicative of the direction of flow through the flow pathway119of the inhalation device100. For example, if the pressure measurement readings reflect a negative change in pressure, the readings may be indicative of air flowing out of the mouthpiece106via the flow pathway119. If the pressure measurement readings reflect a positive change in pressure, the readings may be indicative of air flowing into the mouthpiece106via the flow pathway119. Accordingly, the pressure measurement readings and/or airflow metrics may be used to determine whether a subject is exhaling into the mouthpiece106, which may signal that the subject is not using the device100properly.

The inhalation device100may include a spirometer or similarly operating device to enable measurement of lung function metrics. For example, the inhalation device100may perform measurements to obtain metrics related to a subject's lung capacity. The spirometer or similarly operating device may measure the volume of air inhaled and/or exhaled by the subject. The spirometer or similarly operating device may use pressure transducers, ultrasound, or a water gauge to detect the changes in the volume of air inhaled and/or exhaled.

The data collected from, or calculated based on, the usage of the inhalation device100(e.g. pressure metrics, airflow metrics, lung function metrics, dose confirmation information etc.) may be computed and/or assessed via external devices as well (e.g. partially or entirely). More specifically, the wireless communication circuit129in the electronics module120may include a transmitter and/or receiver (e.g. a transceiver), as well as additional circuitry.

For example, the wireless communication circuit129may include a Bluetooth chip set (e.g. a Bluetooth Low Energy chip set), a ZigBee chipset, a Thread chipset, etc. As such, the electronics module120may wirelessly provide the data, such as pressure measurements, airflow metrics, lung function metrics, dose confirmation information, and/or other conditions related to usage of the inhalation device100, to a mobile device. The electronics module120may also send the timestamps associated with the data. The data may be provided in real time to the external device to enable exacerbation risk prediction based on real-time data from the inhalation device100that indicates time of use, how the inhalation device100is being used, and personalized data about the subject, such as real-time data related to the subject's lung function and/or medical treatment. The external device may include software for processing the received information and for providing compliance and adherence feedback to the subject via a graphical user interface (GUI), such as via a mobile device or via a computer associated with a HCP.

The airflow metrics may include personalized data that is collected from the inhalation device100in real-time, such as one or more of an average flow of an inhalation/exhalation, a peak flow of an inhalation/exhalation (e.g. a maximum inhalation received), a volume of an inhalation/exhalation, a time to peak of an inhalation/exhalation, and/or the duration of an inhalation/exhalation. The airflow metrics may also be indicative of the direction of flow through the flow pathway119. That is, a negative change in pressure may correspond to an inhalation from the mouthpiece106, while a positive change in pressure may correspond to an exhalation into the mouthpiece106. When calculating the airflow metrics, the electronics module120may be configured to eliminate or minimize any distortions caused by environmental conditions. For example, the electronics module120may re-zero to account for changes in atmospheric pressure before or after calculating the airflow metrics. The one or more pressure measurements and/or airflow metrics may be timestamped and stored in the memory of the electronics module120.

In addition to the airflow metrics, the inhalation device100, or another computing device, may use the airflow metrics to generate additional data. For example, the controller of the electronics module120of the inhalation device100may translate the airflow metrics into other metrics that indicate the subject's lung function and/or lung health that are understood to medical practitioners, such as peak inspiratory flow metrics, peak expiratory flow metrics, and/or forced expiratory volume in 1 second (FEV1), for example. The electronics module120of the inhaler may determine a measure of the subject's lung function and/or lung health using a mathematical model such as a regression model. The mathematical model may identify a correlation between the total volume of an inhalation and FEV1. The mathematical model may identify a correlation between peak inspiratory flow and FEV1. The mathematical model may identify a correlation between the total volume of an inhalation and peak expiratory flow. The mathematical model may identify a correlation between peak inspiratory flow and peak expiratory flow.