CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Provisional U.S. Patent Application No. 63/401,861, filed August 29, 2022, the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] 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 various diseases, ailments, and medical conditions. Inhalers, for example, may be used to treat asthma, chronic obstructive pulmonary disease (COPD) and/or cystic fibrosis (CF). While drug delivery devices are designed to deliver an appropriate dose of medication to a patient as part of a therapeutic treatment, the effectiveness of a particular treatment may be influenced by non-physiological factors, such as the patient’s adherence and compliance.

[0003] In the context of a drug therapy, adherence may refer to the degree to which a patient is following a prescribed dosing regimen. For example, if the patient’s prescription calls for two doses each day, and the patient is taking two doses per day, the patient may be considered 100% adherent. If the patient is only taking one dose per day, he or she may be deemed only 50% adherent. In the latter case, the patient may not be receiving the treatment prescribed by his or her doctor, which may negatively affect the efficacy of the therapeutic treatment.

[0004] Compliance may refer to a patient’s technique when using a particular drug delivery device. If the patient is using the device in a manner that is recommended by a doctor or by a manufacturer, the device is likely to deliver the desired dose of medication and the patient may be deemed compliant. However, if the device is not being used properly during drug administration, the device’s ability to deliver a proper dose of medication may be compromised. As such, the patient may be deemed non-compliant. In the case of an inhalation device or inhaler, for example, the patient may need to achieve a minimum inspiratory effort to ensure a full dose of medication is delivered from the device into the patient’s lungs. For some patients, such as children and the elderly, meeting the requirements for full compliance may be difficult, for example, due to physical limitations, such as limited lung function. Accordingly, like adherence, failing to achieve full compliance may reduce the effectiveness of a prescribed treatment.

[0005] A patient's ability to achieve full compliance may be further complicated by certain physical properties of the medication. For example, some respiratory medications may consist of fine particles and/or may lack any odor or taste. Thus, a patient using an inhaler may not be able to correct a non-compliant use because he or she may not be able to immediately detect or sense that medication is being inhaled and/or know whether the amount of inhaled medication complies with the prescription.

[0006] Further, many respiratory diseases, such as asthma and COPD, are life-long conditions where treatment involves the long-term administration of medicaments to manage the patients’ symptoms and to decrease the risks of irreversible changes. There is currently no cure for diseases like asthma and COPD. Treatment takes two forms. First, a maintenance aspect of the treatment is intended to reduce airway inflammation and, consequently, control symptoms in the future. The maintenance therapy is typically provided by inhaled corticosteroids, alone or in combination with long-acting bronchodilators and/or muscarinic antagonists. Secondly, there is also a rescue (or reliever) aspect of the therapy, where patients are given rapid-acting bronchodilators to relieve acute episodes of wheezing, coughing, chest tightness and shortness of breath.

[0007] Sufferers of respiratory diseases may thus be prescribed more than one medication, such as more than one inhaled medication, for controlling their symptoms. The sufferer may alternatively or additionally make use of a plurality of inhalers, each being used at different times/locations, which all deliver the same inhaled medicament. There is a growing desire to monitor administration of such medicaments in ways which are reliable, and convenient from the point of view of the sufferer. Further, such monitoring is also desirable for the patient’s health care provider, who requires a simple and cohesive manner to assess each patient’s adherence and compliance, and view data that indicates the highest risk of exacerbation or indicates that the patient’s treatment regimen should be altered.

[0008] Systems may be designed to monitor a patient’s adherence to a prescribed dosing regimen. For example, systems may be designed to monitor a patient’s adherence by detecting administrations of a medicament by the patient and confirm that the patient is conforming to the prescribed dosing regimen. In order to detect administrations of the medicament, certain components may be added to or included in the drug delivery device used to administer the medicament. For example, components may be added to detect events or actuations at the drug delivery device that are indicative of an administration of the medicament by the drug delivery device. In addition, communication components may be added to the drug delivery device so that certain information associated with a respective administration of medicament by the drug delivery device (e.g., time of administration, number of remaining doses, etc.) can be transmitted to and subsequently stored at and/or analyzed by one or more external devices. Often, these components are add-on components, such as after-market processing and/or communication components that can be attached to a drug delivery device.

[0009] However, while these systems may be used to detect and monitor administrations of a drug delivery device and, by extension, measure a patient’s adherence to (e.g., the degree to which a patient is following) a prescribed dosing regimen, they fail to measure or monitor the patient’s compliance (e.g., the patient’s technique when using a particular drug delivery device). For example, while these systems may detect and monitor administrations of medicament by the drug delivery device, they fail to measure the inhalation parameters (e.g., PIF, volume, etc.) associated with each administration event. That is, although these systems may be capable of monitoring a patient’s adherence to a prescribed dosing regimen, they fail to measure inhalation parameters and thus lack any insight into a patient’s compliance. In failing to measure inhalation parameters, these systems also fail to appreciate the state of the patient’s respiratory disease (e.g., the likelihood that the patient is to experience an exacerbation event), such as the severity of an exacerbation and/or the patient’s general lung health, and/or the patient’s sensitivity to current or changing environmental conditions (e.g., heat, air quality, humidity, etc.).

[0010] Systems that are designed to monitor a patient’s adherence to a prescribed dosing regimen may also provide feedback to the patient based on the patient’s adherence. For example, these systems may provide notifications/alerts to the patient if they fail to follow the prescribed dosing regimen. In addition, these systems may attempt to predict the state of the patient’s respiratory disease (e.g., the likelihood that the patient is to experience an exacerbation event) and/or the patient’s sensitivity to current or changing environmental conditions (e.g, heat, air quality, humidity, etc.) based on their respective adherence. The state of the patient’s respiratory disease and/or sensitivity to current or changing environmental conditions is, however, better predicted (e.g., predicted with a higher degree of accuracy) based the patient’s compliance. As a result, systems that attempt to predict the state of a patient’s respiratory disease and/or their sensitivity to current or changing environmental conditions based only on the patient’s adherence may be inaccurate and/or unreliable. These shortcomings may be further exacerbated when a patient is prescribed multiple medicaments (e.g., a rescue medicament and a maintenance medicament) to treat a respiratory disease. For example, as each of the medicaments may be administered at different times, in response to different conditions, and/or for different purpose, the patient’s compliance with respect to each type of medicament may affect the state of the patient's respiratory disease and/or their sensitivity to current or changing environmental conditions.

SUMMARY

[0011] An inhaler system and methods for performing an inhaler based digital health platform (DHP) synchronization service (DSS) is described herein. The system may include one or more inhalers. Each inhaler may be configured to deliver a medicament to a patient (e g., a controller/ maintenance medicament or a rescue medicament). The inhaler may be a dry -powder inhaler (DPI) or a metered-dose inhaler (MDI). The inhaler may include a processor, a memory, a transceiver, and a sensor. The processor of the inhaler may be configured to perform any combination of the following. The process may be configured to detect, via the sensor, inhalations performed by the patient during a use of the inhaler. The processor may be configured to measure airflow parameters for each of the inhalations. The airflow parameter for each of the inhalations may include any combination of a peak inhalation flow, an inhalation volume, and/or an inhalation duration. The processor may be configured to transmit, via the transceiver, indications of the airflow parameters for each of the inhalations (e.g., directly or indirectly, such as via a user device, to the DHP).

[0012] The inhaler may include an electronics module that includes the processor, the memory, the transceiver, a switch, and the sensor. The inhaler may include a medication reservoir comprising the medicament. The inhaler may include a mouthpiece and a mouthpiece cover. The inhaler may include a yoke mechanically connected to the mouthpiece cover. The yoke may be configured to move to as the mouthpiece cover is opened from a closed position to an open position to cause a dose of medicament to be delivered from the medication reservoir and cause the electronics module to change power states (e.g., from an off or sleep state to an active state).

[0013] In some examples, the sensor may include a pressure sensor that is configured to measure pressure within the inhaler after the mouthpiece cover is moved from a closed position to an open position. In some examples, the sensor may include an acoustic sensor that is configured to detect sound waves after the mouthpiece cover is moved from a closed position to an open position. The inhaler may include a dose counter configured to decrement each time the mouthpiece cover is moved to expose the mouthpiece. The electronics module may be configured to record a dose delivery event each time the switch is engaged and the electronics module to transition to an active state or when measurements received from the sensor are above a threshold or within a range.

[0014] The DHP (e.g., computer-readable medium (CRM) having stored thereon instructions stored thereon) may be configured to receive a third-party identifier of the patient that represents the patient at a third-party server. The DHP may send a provision identifier to the third-party server. The provision identifier may indicate an association between a DSS third- party identifier of the patient and a third-party server identifier. In some examples, the provision identifier may be used only for performing an inhaler based DHP synchronization service with the third-party server. The DSS third-party identifier may be a hash of the third-party identifier of the patient. The DHP may receive event data related to an inhalation through the inhaler by the patient (e.g., from the inhaler of the inhaler system). The event data may include inhalation data of the patient. The event data may be associated with an DHP identifier of the patient that identifies the patient at the DHP. For instance, the DHP may associate a DHP identifier with the event data once it is received at the DHP. The DHP may receive a request for the inhalation data from the third-party server. The request may include the third-party identifier of the patient. The DHP may determine the DHP identifier of the patient based on the provision identifier and the third-party identifier of the patient, and may send the inhalation data of the patient to the third- party server in response to the request.

[0015] A method for performing an inhaler based DHP synchronization service (DSS) may include any combination of the following. The DHP may include any combination of servers and/or CRMs. The method may include receiving event data related to an inhalation through an inhaler by a patient. As noted above, the event data may include inhalation data of the patient. The event data may be associated with a DHP identifier of the patient that identifies the patient at the DHP. The method may include receiving a third-party identifier of a patient that represents the patient at a third-party server. The method may include hashing the third- party identifier of the patient with a hashing algorithm to generate the DSS third-party identifier of the patient. In some examples, the DSS third-party identifier of the patient may be created using a SHA-256 hash function or a SHA-512 hash function. In some examples, the third-party identifier of the patient server may include a Medical Record Number (MRN) of the patient generated by the third-party server. The method may include storing the DSS third-party identifier of the patient (e.g., where the third-party' identifier of the patient is not stored by the DHP).

[0016] The method may include sending a provision identifier to the third-party server. The provision identifier may indicate an association between the DSS third-party identifier of the patient and the third-party identifier. In some examples, the method may include generating the provision identifier. The provision identifier may be a randomly generated value. In some examples, the method may include sending a token to the third-party server, where the token includes the third-party' server identifier and the provision identifier.

[0017] The method may include receiving a request for the inhalation data from the third- party server. The request may include the third-party identifier of the patient. The method may include determining the DHP identifier of the patient based on the provision identifier and the third-party identifier of the patient. In some examples, the method may include receiving the provision identifier and user login credentials. The user login credentials may be associated with the patient at the DHP. For instance, the user login credentials may be received from an identity access management service that is configured to authenticate the user based on a username and password. The method may include determining the DHP identifier of the patient based on the user login credentials, and associating the DHP identifier of the patient with the provision identifier. In some examples, in response to receiving the request for the inhalation data from the third-party server, the method may include hashing the third-party identifier of the patient with the hashing algorithm to generate the DSS third-party identifier of the patient, determining the DHP identifier of the patient based on the provision identifier and the DSS third-party identifier of the patient, and determining the inhalation data associated with the patient based on the DHP identifier of the patient. After the DHP identifier is determined, the method may include sending the inhalation data of the patient to the third-party server in response to the request.

[0018] Using methods described herein, the inhalation data of the patient is sent to the third-party server without exposing the DHP identifier of the patient to the third-party server (e.g., the DHP identifier of the patient may include patient identifiable information (PII) data related to the patient).

[0019] The inhalation data may include a categorization of the inhalation by the user through the inhaler. For instance, the categorization of the inhalation is determined based on one or more of a Peak inspiratory flow (PIF) of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and/or a duration of the inhalation through the inhaler by the patient. The categorization of the inhalation by the user through the inhaler may be one of a low/no inhalation, a good inhalation, or an excessive inhalation.

[0020] In some examples, the method may include sending a subset of the event data to the third-party server in response to the request. For example, the event data further comprises a time of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., deviceSerialNumber), an identification of a prescription type (e.g., prescnptionlD / DrugID) of the inhaler, a categorization of the inhalation by the user through the inhaler, a Peak inspiratory flow (PIF) of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient. In some examples, the subset of the event data includes the time of the inhalation through the inhaler by the patient, the identification of the prescription type of the inhaler, and the categorization of the inhalation by the user through the inhaler.

[0021] In some examples, the method may include generating an application programming interface (API) key that is unique for servers associated with the third party, and sending the API key to the third-party, wherein the request for the inhalation data from comprises the API key. For instance, the method may include sending a DHP-specific API key to the third- party server when sending the token to the third-party server.

[0022] In some examples, the method may include determining that the third-party server is authorized to request any event data and is authorized to request data for the patient. The method may include determining that the third-party server has not exceeded a quota associated with an account of the third-party server.

[0023] In some examples, the method may include sending, from the inhaler to an external device, the event data using an encryption standard (e.g., 128-bit AES), and sending, from the external device to the DHP, the event data, wherein the external device does not store any patient identifiable information (PII) data at the external device. Further, in some examples, the inhaler may include a QR code that includes an encryption key is shared between the inhaler and the external device during a pairing process, where the encryption key may be used to enable the encryption standard during the transfer of event data from the inhaler to the external device. [0024] In some examples, a method for performing an inhaler based DHP synchronization service (DSS). The method may include receiving event data related to an inhalation through an inhaler by the patient, where the event data may include inhalation data of the patient. The event data may be associated with a DHP identifier of the patient that identifies the patient at the DHP. The method may include receiving a request for the inhalation data from the third-party server, where the request may include a third-party identifier of the patient that represents the patient at a third-party server. The method may include determining the DHP identifier of the patient based on a provision identifier and the third-party identifier of the patient, where the provision identifier may indicate an association between a DSS third-party identifier of the patient and a third-party server identifier, and where the DSS third-party identifier may be a hash of the third-party identifier of the patient. The method may include sending the inhalation data of the patient to the third-party server in response to the request.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Fig. 1 A shows a front perspective view of an example inhaler.

[0026] Fig. IB shows a top perspective view of the inhaler shown in Fig. 1 A.

[0027] Fig. 2 shows a cross-sectional interior perspective view of the inhaler shown in

Fig. 1A.

[0028] Fig. 3 provides an exploded perspective view of the example inhaler shown in Fig. 1A.

[0029] Fig. 4 provides an exploded perspective view of a top cap and electronics module of the inhaler shown in Fig. 1 A.

[0030] Fig. 5 shows a graph of airflow rate through the example inhaler shown in Fig. 1 A versus pressure.

[0031] FIG. 6 is a diagram of an example system for collecting event data from one or more inhalers, storing the event data at a digital health platform (DHP), and providing a DHP synchronization service (DSS) that allows one or more third-party servers to access to the event data stored at the DHP via a network.

[0032] FIG. 7 is a call flow diagram that illustrates an example call flow for communicating event data from an inhaler to a DHP, for provisioning a third-party server to enable patient data transfer from the DHP to the third-party server, and for managing data transfer requesting by the DHP from the third-party server.

[0033] FIG. 8 is a block diagram that illustrates an example of a computing device.

[0034] FIG. 9 is a flow diagram that illustrates an example procedure for recording, storing, and communicating event data related to inhalation events in an inhaler system.

[0035] FIG. 10 is a flow diagram that illustrates an example procedure for provisioning a third-party server to enable patient data transfer from a DHP to the third-party server. [0036] FIG. 11 is a flow diagram that illustrates an example procedure for managing data transfer requesting by a DHP from a third-party server.

DETAILED DESCRIPTION

[0037] It should be understood that the detailed description and specific examples, while indicating exemplary embodiments of the apparatus, systems and methods, are intended for purposes of illustration only and are not intended to limit the scope of the invention. These and other features, aspects, and advantages of the apparatus, systems and methods of the present invention will become better understood from the following description, appended claims, and accompanying drawings. It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the figures to indicate the same or similar parts.

[0038] The present disclosure describes devices, systems and methods for sensing, tracking processing, and/or presenting usage conditions and parameters associated with a drug delivery device, such as an inhaler. The devices, systems and methods are described in the context of a breath-actuated inhaler (e.g., also referred to herein as an inhaler) 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.

[0039] 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.

[0040] The symptoms are managed by avoiding triggers and by the use of medicaments, particularly inhaled medicaments. The medicaments include inhaled corticosteroids (ICSs) and bronchodilators.

[0041] 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), fluticasone (propionate or furoate), mometasone (furoate), ciclesonide and dexamethasone (sodium). Parentheses indicate preferred salt or ester forms. Particular mention should be made of budesonide, beclomethasone and fluticasone, especially budesonide, beclomethasone dipropionate, fluticasone propionate and fluticasone furoate.

[0042] Different classes of bronchodilators target different receptors in the airways. Two commonly used classes are |32-agonists and anticholinergics.

[0043] (32- Adrenergic agonists (or “P2-agonists”) act upon the p2-adrenoceptors which induces smooth muscle relaxation, resulting in dilation of the bronchial passages. They tend to be categorized by duration of action. Examples of long-acting p2-agonists (LABAs) include formoterol (fumarate), salmeterol (xinafoate), indacaterol (maleate), bambuterol (hydrochloride), clenbuterol (hydrochloride), olodaterol (hydrochloride), carmoterol (hydrochloride), tulobuterol (hydrochlonde) and vilanterol (triphenylacetate). Examples of short-acting p2-agomsts (SABA) are albuterol (sulfate) and terbutaline (sulfate). Particular mention should be made of formoterol, salmeterol, indacaterol and vilanterol, especially formoterol fumarate, salmeterol xinafoate, indacaterol maleate and vilanterol triphenylacetate.

[0044] 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/pm (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).

[0045] Anticholinergics (or “antimuscarinics”) block the neurotransmitter acetylcholine by selectively blocking its receptor in nerve cells. On topical application, anticholinergics act predominantly on the M3 muscarinic receptors located in the airways to produce smooth muscle relaxation, thus producing a bronchodilatory effect. Examples of long-acting muscarinic antagonists (LAMAs) include tiotropium (bromide), oxitropium (bromide), aclidinium (bromide), umeclidinium (bromide), ipratropium (bromide) glycopyrronium (bromide), oxybutynin (hydrochloride or hydrobromide), tolterodine (tartrate), trospium (chloride), solifenacin (succinate), fesoterodine (fumarate) and darifenacin (hydrobromide). Particular mention should be made of tiotropium, aclidinium, umeclidinium and glycopyrronium, especially tiotropium bromide, aclidinium bromide, umeclidinium bromide and glycopyrronium bromide. [0046] 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. [0047] According to the GINA (Global Initiative for Asthma) Guidelines, a step-wise approach is 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.

[0048] 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.

[0049] 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. Emphy sema 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 localized 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. [0050] 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 p2-agonists and corticosteroids. The medicaments are often administered as a single therapy or as combination treatments.

[0051] 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) pm or a shortacting 02-aginist (SABA) pm. Patient group B are recommended a long-acting muscarinic antagonist (LAMA) or a long-acting (32-aginist (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.

[0052] 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 example, the diagnosis of a clinical asthma exacerbation (CAE) may be based on the American Thoracic Society /European Respiratory Society statement (H.K. Reddel et al., Am J Respir Crit Care Med. 2009, 180(1), 59-99). It includes both a “severe CAE” and a “moderate CAE.” A severe CAE may be defined as a CAE that involves worsening asthma that requires oral steroid (prednisone or equivalent) for at least three days and hospitalization. A moderate CAE may be defined as a CAE that requires oral steroid (prednisone or equivalent) for at least three days or hospitalization.

[0053] 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.

[0054] 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. [0055] Figs. 1 A, IB, and 2-4 provide a non-limiting example arrangement of an inhaler that includes an electronics module. Fig. 1 A provides a front perspective view of an inhaler arrangement 100, referred to as “an inhaler” from here on, according to a non-limiting example. In the illustrated example, the inhaler 100 is a breath-actuated inhaler, although the invention is not so limited, and in other examples, the electronics module may be included in an MDI (e.g, a press-and-breath MDI).

[0056] The inhaler 100 may include a top cap 102, a main housing 104, a mouthpiece 106, a mouthpiece cover 108, an electronics module 120, and an air vent 126. The mouthpiece cover 108 may be hinged to the main housing 104 so that it may open and close to expose the mouthpiece 106. Although illustrated as a hinged connection, the mouthpiece cover 106 may be connected to the inhaler 100 through other types of connections. Moreover, while the electronics module 120 is illustrated as housed within the top cap 102 at the top of the main housing 104, in other examples, the electronics module 120 may be integrated and/or housed within the main body 104 of the inhaler 100.

[0057] The electronics module 120 may include a processor, memory, and/or a communication circuit. The electronics module 120 may include switch(es), sensor(s), shder(s), and/or other instruments or measurement devices configured to determine inhaler usage information. These components are described in more detail below.

[0058] In some examples, the inhaler 100 may include a barcode 42 printed thereon. The barcode 42 in this example is a quick reference (QR) code printed on the uppermost surface of the top cap 102. The electronics module 120 may, for example, be located at least partly within the top cap 102, for example as components of an electronics module (not visible in Fig. 6A).

The electronics module 120 of the inhaler 100 will be described in greater detail with reference to Figs. 2-4.

[0059] The QR code is more clearly visible in Fig. IB which provides a view from directly above the top cap 102 of the inhaler 100 shown in Fig. 1A. The QR code 42 may provide a facile way of pairing the respective inhaler 100 with one or more external devices, such as a user device, in examples in which the external device comprises a suitable optical reader, such as a camera, for reading the QR code.

[0060] The bar code 42 may comprise an identifier which is assigned to the respective medicament of the inhaler 100, as previously described. Table 1 provides a non-limiting example of the identifiers that may be identified by the bar code 42.

Table 1

[0061] As shown in Table 1, the identifier may denote the dose strength and the total dose count of the inhaler 100 prior to use. The barcode 42 on the inhaler 100 may, for instance, further comprise a security key (e.g., in the form of a series of alphanumerical characters) for preventing unauthorized users from accessing the inhaler 100. The barcode 42 may provide a passkey, which may allow synchronization between the inhaler 100 and one or more external devices. The passkey and, in turn, event data (e.g, inhalation and/or usage data stored on the inhaler 100, described in more detail herein) may communicated to an external device. The event data may not be associated with the particular patient until the data is synchronized with a single patient account (e.g., at the DHP, as described in more detail herein).

[0062] Fig. 2 provides a cross-sectional interior perspective view of the inhaler 100. Inside the main housing 104, the inhaler 100 may include a medication reservoir 110 and a dose metering assembly. For example, the inhaler 100 may include a medication reservoir 110 (e.g., a hopper), a bellows 112, a bellows spring 114, a yoke (not visible), a dosing cup 116, a dosing chamber 117, a deagglomerator 121, and a flow pathway 119. The medication reservoir 110 may include medication, such as dry powder medication, for delivery to the patient. Although illustrated as a combination of the bellows 112, the bellows spring 114, the yoke, the dosing cup 116, the dosing chamber 117, and the deagglomerator 121, the dose metering assembly may include a subset of the components described and/or the inhaler 100 may include a different dose metering assembly (e.g. , based on the type of inhaler, the type of medication, etc ). For instance, in some examples the medication may be included in a blister strip and the dose metering assembly, which may include one or more wheels, levers, and/or actuators, is 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. [0063] When the mouthpiece cover 108 is moved from the closed to the open position, the dose metering assembly of the inhaler 100 may pnme a dose of medicament. For instance, when the mouthpiece cover 108 is moved from the closed to the open position, the dose metering assembly of the inhaler 100 may prepare a dose of medicament (e.g, dry-powder medication) for inhalation by the patient, for example, by peeling a cover off of a blister that comprises a dose of medication, by breaking open a capsule that comprises medication, etc. In the illustrated example of FIG. 2, the mouthpiece cover 108 being moved from the closed to the open position may cause the bellows 112 to compress to deliver a dose of medication from the medication reservoir 110 to the dosing cup 116. Thereafter, a patient may inhale through the mouthpiece 106 in an effort to receive the dose of medication.

[0064] The airflow generated from the patient’s inhalation may cause the deagglomerator 121 to aerosolize the dose of medication by breaking down the agglomerates of the medicament in the dose cup 116. The deagglomerator 121 may be configured to aerosolize the medication when the airflow through the flow pathway 119 meets or exceeds a particular rate, or is within a specific range. When aerosolized, the dose of medication may travel from the dosing cup 116, into the dosing chamber 1 17, through the flow' pathway 1 19, and out of the mouthpiece 106 to the patient. If the airflow through the flow pathway 119 does not meet or exceed a particular rate, or is not within a specific range, the medication may remain in the dosing cup 116. In the event that the medication in the dosing cup 116 has not been aerosolized by the deagglomerator 121, another dose of medication may not be delivered from the medication resen' oir 110 when the mouthpiece cover 108 is subsequently opened. Thus, a single dose of medication may remain in the dosing cup until the dose has been aerosolized by the deagglomerator 121. When a dose of medication is delivered, a dose confirmation may be stored in memory at the inhaler 100 (e.g., as event data).

[0065] As the patient inhales through the mouthpiece 106, air may enter the air vent to provide a flow of air for delivery of the medication to the patient. The flow pathway 119 may extend from the dosing chamber 117 to the end of the mouthpiece 106, and include the dosing chamber 117 and the internal portions of the mouthpiece 106. The dosing cup 116 may reside within or adjacent to the dosing chamber 117. Further, the inhaler 100 may include a dose counter 111 that is configured to be initially set to a number of total doses of medication within the medication reservoir 110 and to decrease by one each time the mouthpiece cover 108 is moved from the closed position to the open position.

[0066] The top cap 102 may be attached to the main housing 104. For example, the top cap 102 may be attached to the main housing 104 through the use of one or more clips that engage recesses on the mam housing 104. The top cap 102 may overlap a portion of the main housing 104 when connected, for example, such that a substantially pneumatic seal exists between the top cap 102 and the main housing 104.

[0067] Fig. 3 is an exploded perspective view of the example inhaler 100 with the top cap 102 removed to expose the electronics module 120. As shown in Fig. 3, the top surface of the main housing 104 may include one or more (e.g, two) orifices 146. One of the orifices 146 maybe configured to accept a slider 140. For example, when the top cap 102 is attached to the main housing 104, the slider 140 may protrude through the top surface of the main housing 104 via one of the orifices 146.

[0068] Fig. 4 is an exploded perspective view of the top cap 102 and the electronics module 120 of the example inhaler 100. As shown in Fig. 4, the slider 140 may define an arm 142, a stopper 144, and a distal end 145. The distal end 145 may be a bottom portion of the slider 140. The distal end 145 of the slider 140 may be configured to abut the yoke that resides within the main housing 104 (e.g.. when the mouthpiece cover 108 is in the closed or partially open position). The distal end 145 may be configured to abut a top surface of the yoke when the yoke is in any radial orientation. For example, the top surface of the yoke may include a plurality of apertures (not shown), and the distal end 145 of the slider 140 may be configured to abut the top surface of the yoke, for example, whether or not one of the apertures is in alignment with the slider 140.

[0069] The top cap 102 may include a slider guide 148 that is configured to receive a slider spring 146 and the slider 140. The slider spring 146 may reside within the slider guide 148. The slider spring 146 may engage an inner surface of the top cap 102, and the slider spring 146 may engage (e.g., abut) an upper portion (e.g., a proximate end) of the slider 140. When the slider 140 is installed within the slider guide 148, the slider spring 146 may be partially compressed between the top of the slider 140 and the inner surface of the top cap 102. For example, the slider spring 146 may be configured such that the distal end 145 of the slider 140 remains in contact with the yoke when the mouthpiece cover 108 is closed. The distal end 145 of the slider 145 may also remain in contact with the yoke while the mouthpiece cover 108 is being opened or closed. The stopper 144 of the slider 140 may engage a stopper of the slider guide 148, for example, such that the slider 140 is retained within the slider guide 148 through the opening and closing of the mouthpiece cover 108, and vice versa. The stopper 144 and the slider guide 148 may be configured to limit the vertical (e.g., axial) travel of the slider 140. This limit may be less than the vertical travel of the yoke. Thus, as the mouthpiece cover 108 is moved to a fully open position, the yoke may continue to move in a vertical direction towards the mouthpiece 106 but the stopper 144 may stop the vertical travel of the slider 140 such that the distal end 145 of the slider 140 may no longer be in contact with the yoke. Although described in the context of vertical movement, any combination of the yoke and/or the slider 140 may be configured to move in a different direction in response to movement of the mouthpiece cover 108.

[0070] More generally, the yoke may be mechanically connected to the mouthpiece cover 108 and configured to move to compress the bellows spring 114 as the mouthpiece cover 108 is opened from the closed position and then release the compressed bellows spring 114 when the mouthpiece cover reaches the fully open position, thereby causing the bellows 112 to deliver the dose from the medication reservoir 110 to the dosing cup 116. The yoke may be in contact with the slider 140 when the mouthpiece cover 108 is in the closed position. The slider 140 may be arranged to be moved by the yoke as the mouthpiece cover 108 is opened from the closed position and separated from the yoke when the mouthpiece cover 108 reaches the fully open position. This arrangement may be regarded as a nondimiting example of the previously described dose metering assembly, since opening the mouthpiece cover 108 causes the metering of the dose of the medicament.

[0071] The movement of the slider 140 during the dose metering may cause the slider 140 to engage and actuate a switch 130. The sw itch 130 may trigger the electronics module 120 to register the dose metering. The slider 140 and switch 130 together with the electronics module 120 may thus be regarded as being included in the use determination system 12 described above. Actuation of the switch 130 by the slider 140 may also, for example, cause the electronics module 120 to transition from the first power state to a second power state, and to sense an inhalation by the patient from the mouthpiece 106.

[0072] The electronics module 120 may include a printed circuit board (PCB) assembly

122, a switch 130, a power supply (e.g., a battery 126), and/or a battery holder 124. The PCB assembly 122 may include surface mounted components, such as a sensor system 128, a wireless communication circuit 129, the switch 130, and or one or more indicators (not shown), such as one or more light emitting diodes (LEDs). The electronics module 120 may include a controller (e.g., a processor) 125 and/or memory (not shown). The processor 125 and/or memory' may be physically distinct components of the PCB 122. Alternatively, the processor 125 and memory may be part of another chipset mounted on the PCB 122, for example, the wireless communication circuit 129 may include the processor 125 and/or memory for the electronics module 120.

[0073] The processor 125 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 125 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the electronics module 120 to operate. [0074] The processor 125 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 processor 125. The processor 125 may also access data from, and store data in, memory that is not physically located within the electronics module 120, such as on an external device (e.g., a user device and/or the DHP).

[0075] The memory may comprise a computer-readable storage media or machine- readable storage media that maintains computer-executable instructions for performing one or more as described herein. For example, the memory may comprise computer-executable instructions or machine-readable instructions that include one or more portions of the procedures described herein. The processor 125 of the electronics module 120 may access the instructions from memory for being executed to cause the processor 125 of the electronics module 120 to operate as described herein, or to operate one or more other devices as described herein. The memory may comprise computer-executable instructions for executing configuration software. For example, the computer-executable instructions may be executed to perform, in part and/or in their entirety, one or more procedures described herein. Further, the memory may have stored thereon one or more setings, data (e.g., event data), and/or control parameters associated with the electronics module 120.

[0076] The batery 126 may provide power to the components of the PCB 122. The batery 126 may be any suitable source for powering the electronics module 120, such as a coin cell battery, for example. The batery 126 may be rechargeable or non-rechargeable. The batery 126 may be housed by the batery holder 124. The batery holder 124 may be secured to the PCB 122 such that the batery 126 maintains continuous contact with the PCB 122 and/or is in electrical connection with the components of the PCB 122. The battery 126 may have a particular batery capacity that may affect the life of the batery 126. As will be further discussed below, the distribution of power from the batery 126 to the one or more components of the PCB 122 may be managed to ensure the batery 126 can power the electronics module 120 over the useful life of the inhaler 100 and/or the medication contained therein.

[0077] The wireless communication circuit 129 may include a transceiver, and as such may be configured to transmit and/or receive RF signals via a Wi-Fi communication link, a WiMAX 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 wireless communication circuit 129 may be configured to communicate data recorded by the electronics module 120 and/or stored within memory of the electronics module 120 to one or more external devices, such as a user device (e.g., smartphone, tablet, computer, etc.), a digital health platform (DHP), and/or any other external device (e.g., server).

[0078] The sensor system 128 may include one or more sensors. For example, the sensor system 128 may include one or more sensors, for example, of different types, such as, but not limited to one or more pressure sensors, temperature sensors, humidity sensors, orientation sensors, acoustic sensors, and/or optical sensors. The one or more pressure sensors 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 sensor system 128 may be configured to provide an instantaneous reading (e.g, pressure reading) to the processor 125 of the electronics module 120 and/or aggregated readings (e.g., pressure readings) over time. As illustrated in Figs. 3 and 4, the sensor system 128 may reside outside the flow pathway 119 of the inhaler 100 but may be pneumatically coupled to the flow pathway 119.

[0079] The processor 125 of the electronics module 120 may receive signals corresponding to measurements from the sensor system 128. The processor 125 may record event data. The event data may include data stored within the memory of the electronics module 120 and generated in response to an inhalation event at the inhaler by the user. As described in more detail herein, the event data may be supplemented by the DHP with additional data, such as PII data specific to the patient. The event data may include any combination of a time of a mouthpiece cover event (e.g., the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g, which may be the same as the mouthpiece cover event, in some examples), a time of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g., an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler 100), a categorization of the inhalation by the user through the inhaler, a Peak inspiratory flow (PIF) of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient.

[0080] The processor 125 may calculate or determine one or more airflow metrics using the signals received from the sensor system 128. The airflow metrics may be indicative of a profile of airflow through the flow pathway 119 of the inhaler 100. For example, if the sensor system 128 records a change in pressure of 0.3 kilopascals (kPa), the electronics module 120 may determine that the change corresponds to an airflow rate of approximately 45 liters per minute (Lpm) through the flow pathway 119.

[0081] Fig. 5 shows a graph 500 of airflow rates versus pressure. The airflow rates and profile shown in Fig. 5 are merely examples and the determined rates may depend on the size, shape, and design of the inhaler 100 and its components.

[0082] An external device (e.g, a user device and/or the DHP) may supplement the event data by comparing signals received from the sensor system 128 and/or the determined airflow metrics to one or more thresholds or ranges, for example, as part of an assessment of how the inhaler 100 is 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, external device may determine that there has been no inhalation or an insufficient inhalation from the mouthpiece 106 of the inhaler 100. If the determined airflow metric corresponds to an inhalation with an airflow rate above a particular threshold, the electronics module 120 may determine that there has been an excessive inhalation from the mouthpiece 106. If the determined airflow metric corresponds to an inhalation with an airflow rate within a particular range, the electronics module 120 may determine that the inhalation is “good”, or likely to result in a full dose of medication being delivered.

[0083] The pressure measurement readings and/or the computed airflow metrics may be indicative of the quality or strength of inhalation from the inhaler 100. 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 event data.

[0084] 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 patient does not inhale from the mouthpiece 106 after opening the mouthpiece cover 108 and during the measurement cycle. The no inhalation event may also occur when the patient’s inspiratory effort is insufficient to ensure proper delivery of the medication via the flow pathway 119, such as when the inspi ratory effort generates insufficient airflow to activate the deagglomerator 121 and, thus, aerosolize the medication in the dosing cup 116.

[0085] 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 patient inhales from the mouthpiece 106 after opening the mouthpiece cover 108 and the patient’s inspiratory effort causes at least a partial dose of the medication to be delivered via the flow pathway 1 19. That is, the inhalation may be sufficient to activate the deagglomerator 121 such that at least a portion of the medication is aerosolized from the dosing cup 116.

[0086] 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 patient inhales from the mouthpiece 106 after opening the mouthpiece cover 108 and the patient's inspiratory effort is sufficient to ensure proper delivery of the medication via the flow pathway 119, such as when the inspiratory effort generates sufficient airflow to activate the deagglomerator 121 and aerosolize a full dose of medication in the dosing cup 116.

[0087] 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 patient’s inspiratory' effort exceeds the normal operational parameters of the inhaler 100. The excessive inhalation event may also occur if the device 100 is not properly positioned or held during use, even if the patient'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 patient is inhaling from the mouthpiece 106.

[0088] 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.

[0089] The measurement readings and/or the computed airflow metrics may also be indicative of the direction of flow through the flow pathway 119 of the inhaler 100. For example, if the pressure measurement readings reflect a negative change in pressure, the readings may be indicative of air flowing out of the mouthpiece 106 via the flow' pathway 119. If the pressure measurement readings reflect a positive change in pressure, the readings may be indicative of air flowing into the mouthpiece 106 via the flow pathway 119. Accordingly, the measurement readings and/or airflow metrics may be used to determine whether a patient is exhaling into the mouthpiece 106, which may signal that the patient is not using the device 100 properly.

[0090] The inhaler 100 may include a spirometer or similarly operating device to enable measurement of lung function metrics For example, the inhaler 100 may perform measurements to obtain metrics related to a patient’s lung capacity. The spirometer or similarly operating device may measure the volume of air inhaled and/or exhaled by the patient. 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.

[0091] As noted herein, the data collected from, or calculated based on, the usage of the inhaler 100 (e.g., pressure metrics, airflow metrics, lung function metrics, dose confirmation information , etc.) may be referred to as event data. The event data may be computed and/or assessed via external devices (e.g., partially or entirely). More specifically, the wireless communication circuit 129 in the electronics module 120 may include a transmitter and/or receiver (e.g., a transceiver), which may be configured to send the event data associated with an inhaler to one or more external devices (e.g., user devices and/or a DHP).

[0092] The event data may include any combination of a time of a mouthpiece cover event (e.g., the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g., which may be the same as the mouthpiece cover event, in some examples), a time of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g., an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler 100), a categorization of the inhalation by the user through the inhaler, a Peak inspiratory flow (PIF) of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient.

[0093] As such, the electronics module 120 may wirelessly provide the event data, such as pressure measurements, airflow metrics, lung function metrics, dose confirmation information, and/or other conditions related to usage of the inhaler 100, to an external device. The event data may be provided in real time to the external device to enable exacerbation risk prediction based on real-time data from the inhaler 100 that indicates time of use, how the inhaler 100 is being used, and personalized data about the patient, such as data related to the patient’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 patient via a graphical user interface (GUI). The graphical user interface may be included in, or may define, the user interface 38 included in the external device.

[0094] The airflow metrics may include 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 pathway 119. That is, a negative change in pressure may correspond to an inhalation from the mouthpiece 106, while a positive change in pressure may correspond to an exhalation into the mouthpiece 106. When calculating the airflow metrics, the electronics module 120 may be configured to eliminate or minimize any distortions caused by environmental conditions. For example, the electronics module 120 may 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 module 120.

[0095] In addition to the airflow metrics, the inhaler 100, or another computing device, may use the airflow metrics to generate additional event data. For example, the processor 125 of the electronics module 120 of the inhaler 100 may translate the airflow metrics into other metrics that indicate the patient’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 module 120 of the inhaler may determine a measure of the patient’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.

[0096] In a connected state, the communication circuit and memory may be powered on and the electronics module 120 may be “paired” with an external device, such as a smart phone. The processor 125 may retrieve data from the memory and wirelessly transmit the data to the external device. The processor 125 may retrieve and transmit the data currently stored in the memory. The processor 125 may also retrieve and transmit a portion of the data currently stored in the memory. For example, the processor 125 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. Alternatively, the external device may request specific data from the processor 125, such as any data that has been collected by the electronics module 120 after a particular time or after the last transmission to the external device. The processor 125 may retrieve the specific data, if any, from the memory and transmit the specific data to the external device.

[0097] The data stored in the memory of the electronics module 120 (e.g., the signals generated by the switch 130, the pressure measurement readings taken by the sensory system 128 and/or the airflow metrics computed by the processor 125 of the PCB 122) may be transmitted to an external device, which may process and analyze the data to determine the usage parameters associated with the inhaler 100. Further, a mobile application residing on the mobile device may generate feedback for the user based on data received from the electronics module 120. For example, the mobile application may generate daily, weekly, or monthly report, provide confirmation of error events or notifications, provide instructive feedback to the patient, and/or the like.

[0098] FIG. 6 is a diagram of an example system 600 for collecting event data from one or more inhalers 630, storing the event data at a digital health platform (DHP) 610, and providing a DHP synchronization service (DSS) that allows one or more third-party servers 620 to access to the event data stored at the DHP 610 via a network, such as a public and/or private network 640. The network 640 may include any combination of public and/or private networks, such as, but not limited to the Internet, a cloud network, and/or the like.

[0099] The inhaler 630 may be an example of the inhaler 100 described herein. Although only one inhaler 630 is illustrated in FIG. 6, the system 600 may comprise a plurality of inhalers 630, where each inhaler 630 may be associated with a different patient of a plurality of different patients. Further, some patients may be associate with a plurality of inhalers 630 (e.g., one or more rescue inhalers and/or maintenance inhalers). The inhaler 630 may include medicament, such as a rescue medicament and/or a maintenance medicament. Accordingly, each inhaler 630 may be associated with a patient, and may be configured to generate event data associated with a use (e.g, an inhalation) of the inhaler by the patient.

[0100] As noted above, the event data may include any combination of a time of a mouthpiece cover event (e.g, the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g, which may be the same as the mouthpiece cover event, in some examples), a time and/or date of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g., an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler 100), a categorization of the inhalation by the user through the inhaler, and/or one or more inhalation parameters relating to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and/or a duration of the inhalation through the inhaler by the patient. Inhalation data may include any combination of event data that is specific to (e.g, characterizes) the inhalation through the inhaler 630 by the user, such as ), a categorization of the inhalation by the user through the inhaler (e.g., low inhalation, good inhalation, excessive inhalation, exhalation) and/or any combination of inhalation parameters relating to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, the inhaled volume of the inhalation through the inhaler by the patient, and/or the duration of the inhalation through the inhaler by the patient. Further, as noted above, the event data may be supplemented by the DHP with additional data, such as PII data specific to the patient.

[0101] The inhaler 630 may be configured to communicate the event data directly or indirectly to the DHP 610. For example, the inhaler 630 may be configured to communicate the event data to a user device (e.g. , a smartphone or tablet), and the user device may send the event data to the DHP 610. For instance, a user device may transfer data (e.g. , through a public and/or private network) to the DHP 610 using, for example, a communication interface published by the DHP 610, such as a dedicated API. For example, the user device may send event data relating to one or more paired inhalers to the DHP 610.

[0102] The DHP 610 may include and/or reside on a server or combination of servers that is configured to receive data from various sources, such as the inhalers 630. The DHP 610 may be configured to receive event data from one or more inhalers 630, store the event data at the DHP 610 (e.g., where the event data is stored in associated with the patient using the inhaler 630), and provide a DHP synchronization service (DSS) that allows one or more third-party servers 620 to access and receive the event data associated with a patient and stored at the DHP 610. Examples of a DHP are described in greater detail in U.S. Patent Publication No. US 2022/0148730 Al, published May 12, 2022, entitled Inhaler System, the entire disclosure of which is hereby incorporated by reference.

[0103] The DHP 610 may include one or more processors, a transceiver, and/or computer software residing on a computer readable storage medium (e.g., memory), which may be configured to cause the one or more processors of the DHP 610 perform the functions described in relation to the DHP 610. As noted above, the DHP 610 is configured to receive and aggregate data from a plurality of inhalers 630 (e.g., via a respectively paired user device), which may be associated with a plurality of different patients.

[0104] After receiving the event data from the inhaler, the DHP 610 (e.g. , and/or an intervening user device) may perform certain calculations and/or conversions on the received event data. For example, the DHP 610 (e.g., and/or an intervening user device) may convert a relative timestamp of the detected usage event to a local time stamp (e.g., based on the local time at which the usage event occurred). Similarly, the DHP 610 (e.g., and/or an intervening user device) may convert one or more inhalation parameters. For example, the DHP 610 (e.g., and/or an intervening user device) may further a given usage event into usage event category, for example, based on the event data. For example, as described herein, the categories of inhalation events may include: no inhalation events, low inhalations events, good inhalation events, excessive inhalation events, exhalation events, actuation events, error events, underuse events, overuse events, inhaler cap openings or medication priming events (e.g., such as opening of a blister strip, the opening of a capsule, etc., as described further herein), etc.

[0105] In some examples, the DHP 610 may be configured to associate PII with the event data. For example, the DHP 610 may be configured to associate a patient (e.g., patient data) with the event data. In some instances, the patient data may include a unique identifier (e.g., alphanumeric, such as a medical record number (MRN)) that identifies the patient at the DHP 610, which may be referred to as a DHP identifier of the patient. The patient data may include the patient’s legal name (e.g., first, middle, and/or last), date of birth, and/or other PII data. Further, in some examples, the patient data may include a username and password that, for instance, may be used by the patient to access the records at the DHP 610 (e.g., through a web portal and/or via a user device).

[0106] The third-party server 620 may be associated with an electronic medical record (EMR) database, an Electronic Health Record (EHR) database, an electronic medical billing system, and/or the like. The third-party server 620 may include data (e g., health data and/or PII data) related to one or more patients. The patients may be the same as and/or different from the patients that are associated with the inhalers 630 of the system 600. Similar to the DHP 610, the third-party server 620 may associate a patient with a unique identifier (e.g. , alphanumeric, such as a medical record number (MRN)) that identifies the patient at the third-party server 620, which may be referred to as a third-party identifier of the patient.

[0107] The third-party server 620 may not have direct access to the event data (e.g., including the inhalation data) from the inhalers 630 of the system 600. As such, the DHP 610 may be configured to expose a communication interface published by the DHP 610, such as a dedicated API, that allows the third-party server 620 to request event data for patients that are part of both the third-party server 620 and the DHP 610.

[0108] The transfer of PII data is typically regulated, restricted, or completely forbidden.

Many jurisdictions have adopted data protections regulations (e.g, such as the General Data Protection Regulation (GDPR)) to regulate and/or limit the transfer of PII data between parties. PII can include sensitive personal information, such as a personal identification number: social security number (SSN), passport number, driver's license number, taxpayer identification number, patient identification number, financial account number, credit card number, a date of birth, personal address information (e.g., street address or email address), a personal telephone number, etc. In the wrong hands, PII can be used for unlawful purposes, such as identity theft or fraud. Therefore, the system 600 may include safeguards to help protect PII data during the transfer of event data between the DHP 610 and one or more third party servers 620.

[0109] The DHP 610 may allow for the transfer of event data related to one or more patients without exposing the identifier of the patient that is stored at the DHP 610 (e.g., the DHP identifier of the patient). This functionality may be referred to as a DHP synchronization service (DSS) that is provided by the DHP 610. Further, the DHP 610 may allow for the transfer of event data related to one or more patients without requiring that the DHP 610 store the third- party identifier of the patient. As such, the DHP 610 may allow for the transfer of event data related to one or more patients to one or more third-party servers 620 without exposing the DHP identifier of the patient (e.g, without sending or communicating the DHP identifier of the patient with the th i rd- party server and/or any server outside of the DHP 610), and also without requiring that the DHP 610 store the third-party identifier of the patient. Since the DHP identifier of the patient and/or the third-party identifier of the patient may include and/or be used to reference PII data related to the patient, it is important that the exposure and/or storage of these identifiers be minimized.

[0110] As described in more detail herein, the DHP 610 may receive a third-party identifier of a patient that represents the patient at the third-party server 620. The DHP 610 may use a provision identifier to enable the DSS service. For instance, the DHP 610 may hash the third-party identifier of the patient with a hashing algorithm and generate a DSS third-party identifier of the patient. The DSS third-party identifier of the patient may be an identifier that is generated by the DHP 610 that is specific to the patient and the third-party server 620 and used to enable the DSS service at the DHP 610. The DHP 610 may store the DSS third-party identifier of the patient, but as noted above, in some examples, the DHP 610 does not store the third-party identifier of the patient (e.g., in long-term memory).

[OH l] The provision identifier may indicate the association between the DSS third-party identifier of the patient and a third-party server identifier. The third-party server identifier may identify the third-party server 620 for the DSS service, or alternatively any server associated with the third party that is authorized to make data requests through the DSS service. The DHP 610 may generate the provision identifier. In some examples, the provision identifier may be a randomly generated value. The DHP 610 may send the provision identifier to the third-party server 620.

[0112] At this stage, the DHP 610 may have stored (e.g., in long-term memory) the provision identifier, the DSS third-party identifier of the patient, and the third-party server identifier. These values may be stored in association with one another. But, at this stage, the DHP 610 is unaware which patient (e.g, which DHP identifier) is associated with these values due to the hashing performed on the third-party identifier to produce the DSS third-party identifier of the patient, which renders reverse engineering of the third-party identifier from the DSS third-party identifier of the patient practicably impossible. Further, it should be appreciated that, in some examples, the DHP 610 generated the third-party server identifier during a provisioning process that was specific to the third-party server 620.

[0113] In some examples, to determine the DHP identifier of the patient in response to the request, the DHP 610 may receive the provision identifier and user login credentials (e.g., a username and password). The user login credentials are associated with the patient at the DHP. For instance, in some examples, the third-party server 620 may redirect the user to a login page that requests that the user enter their user login credentials, and along with the user login credentials, the DHP 610 may also receive the provision identifier (e.g., the third-party server 620 may have stored the provision identifier in the patient’s browser cache prior to redirecting the user to a website that requests that the user enter their user login credentials).

[0114] Based on the user login credentials, the DHP 610 may identify the DHP identifier of the patient. Further, based on the provision identifier that was received along with the user login credentials, the DHP 610 may associate the DHP identifier of the patient with the provision identifier, the DSS third-party identifier of the patient, and/or the third-party server identifier. For instance, the DHP 610 may be configured to store (e.g., in long-term memory) the DHP identifier of the patient, the DSS third-party identifier of the patient, the provision identifier, and the third-party server identifier (e.g., store the values in association with one another). Next, in some examples, the DHP 610 may send a validation message to the third-party server 620 to, for example, provide a confirmation to the third-party server 620 that the third-party server 620 may request data from the DHP 610 relating to the patient associated with the third-party patient identifier. Accordingly, using this stored association of values, the DHP 610 may enable the third-party server 620 to request data associated with this patient.

[0115] The DHP 610 may receive a request for the inhalation data for the patient from the third-party server 620 (e.g, after provisioning the patient and third-party server 620). The request may include the third-party identifier of the patient. The DHP 610 may determine the DHP identifier of the patient based on the provision identifier and the third-party identifier of the patient, and after determining the DHP identifier of the patient, the DHP 610 may send the inhalation data of the patient to the third-party server in response to the request.

[0116] FIG. 7 is a call flow diagram 700 that illustrates an example call flow for communicating event data from an inhaler 730 to a DHP 740, for provisioning a third-party server 750 to enable patient data transfer from the DHP 740 to the third-party server 750, and for managing data transfer requesting by the DHP 740 from the third-party server 750. The inhaler 730 may be an example of the inhaler 100 and/or the inhaler 630 described herein. The DHP 740 may be an example of the DHP 610. The third-party server 750 may be an example of the third- party server 620.

[0117] The call flow diagram 700 may be divided generally into three sub-processes: (1) a process related to the communication of event data from the inhaler 730 to the DHP 740, (2) a process related to the provisioning of the third-party server 750 with the DHP 740 to enable the transfer of event data from the DHP 740 to the third-party server 750, and (3) a process related to the management, by the DHP 740, of requests from the third-party server 750 for event data from the DHP 740 (e.g., after provisioning). Although illustrated as three sub-processes, the steps described with reference to the call flow diagram 700 may be performed in any order, and any of these steps may be omitted in some examples.

[0118] The inhaler 730 may include medicament, such as a rescue medicament and/or a maintenance medicament. The inhaler 730 may be associated with a patient, and may be configured to generate event data associated with a use (e.g, an inhalation) of the inhaler by the patient. As noted above, the event data may include any combination of a time of a mouthpiece cover event (e.g, the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g., which may be the same as the mouthpiece cover event, in some examples), a time and/or date of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g, an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler 100), a categorization of the inhalation by the user through the inhaler, and/or one or more inhalation parameters related to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient.

[0119] At 702, the inhaler 730 may be configured to communicate the event data directly or indirectly to the DHP 740. For example, the inhaler 730 may be configured to communicate the event data to a user device (e.g. , a smartphone or tablet), and the user device may send the event data to the DHP 740. In some examples, the user device may transfer data (e.g , through a public and/or private network) to the DHP 740 using, for example, a communication interface published by the DHP 740, such as a dedicated API. For example, the user device may send event data relating to one or more paired inhalers to the DHP 740. In some examples, the user device may be configured to supplemented by the DHP with additional data and/or may be configured to analyze the event data and alter or update the event data based on computing capabilities at the user device (e.g, geo-tag the event data, determine one or more categorizations of the inhalation parameters, etc.). In other examples, the inhaler 730 may be configured to communicate the event data directly to the DHP 740 (e.g., via a cellular wireless communication interface). The inhaler 730 may be configured to communicate the event data for one or more inhalation events to the DHP 740 in a single communication.

[0120] At 704, the DHP 740 may be configured to store the event data (e.g, including the inhalation data) in memory' at the DHP 740 (e.g, in long-term memory). In some examples, the DHP 740 may be configured to supplement the event data with additional data, such as PII data specific to the patient. For example, the DHP 740 may determine the patient that is associated with the event data, and store the event data with an identifier of the patient (e.g. , a patient identifier that is specific to the patient at the DHP 740, which may be referred to as the DHP identifier of the patient). Further, in some examples, the DHP 740 may be configured to associate PII with the event data (e.g. , using the DHP identifier of the patient). For example, the DHP 740 may be configured to associate the patient’s legal name (e.g, first, middle, and/or last), date of birth, and/or other PII data. Further, in some examples, the DHP 740 may associate a username and password with the event data that, for instance, may be used by the patient to access the records at the DHP 740 (e.g, through a web portal and/or via a user device).

Accordingly, the DHP 740 may comprise event data for a plurality of different patients, and for each patient, the DHP 740 may comprises event data relating to a plurality of different inhalations, and the event data for a patient may be associated with the DHP identifier of the patient (e.g, a patient identifier that is specific to the patient at the DHP 740).

[0121] At 706, the third-party server 750 may be configured to send a request to the DHP 740. The request may be to provision the third-party server 750 (e.g. , to allow the third-party server 750 to request, at a later time, even data related to the patient) and/or the request may itself be a request for event data related to the patient. In some examples, the DHP 740 may be configured to expose a communication interface published by the DHP 740, such as a dedicated API, that allows the third-party server 750 to send requests to the DHP 740. The request sent from the third-party server 750 may include a third-party identifier of the patient. As noted above, the third-party server 750 may associate the patient with a unique identifier (e.g, alphanumeric, such as a medical record number (MRN)) that identifies the patient at the third- party server 750.

[0122] As described in more detail below, the DHP 740 may allow for the transfer of event data related to one or more patients without exposing the DHP identifier of the patient (e.g, without sending or communicating the DHP identifier of the patient with the third-party server 750 and/or any server outside of the DHP 740). Further, the DHP 740 may allow for the transfer of event data related to one or more patients without requiring that the DHP 740 store the third-party identifier of the patient. Accordingly, the DHP 740 may allow for the transfer of event data related to one or more patients to one or more third-party servers 750 without exposing the DHP identifier of the patient, and also without requiring that the DHP 740 store the third-party identifier of the patient. Since the DHP identifier of the patient and/or the third-party identifier of the patient may include and/or be used to reference PII data related to the patient, it is important that the exposure and/or storage of these identifiers be minimized.

[0123] At 708, the DHP 740 may generate a hash of the third-party identifier of the patient to generate a DSS third-party identifier of the patient. For instance, the DHP 740 may hash the third-party identifier of the patient using a hashing algorithm to generate the DSS third- party identifier of the patient, for example, using a SHA-256 hash function or a SHA-512 hash function. As noted herein, the DSS third-party identifier of the patient may be an identifier that is generated by the DHP 740 that is specific to the patient and the third-party server 620 and used to enable the DSS service at the DHP 740. The DHP 740 may store the DSS third-party identifier of the patient, but as noted above, in some examples, the DHP 740 does not store the third-party identifier of the patient (e.g., in long-term memory). Although described in context of using a hashing algorithm, in other examples, the DHP 740 may be configured to generate the DSS third-party identifier of the patient based on the third-party' identifier of the patient using another means.

[0124] At 710, the DHP 740 may be configured to generate a provision identifier that indicates an association between the DSS third-party identifier of the patient and a third-party server identifier. As such, the provision identifier may indicate the association between the DSS third-party identifier of the patient and a third-party server identifier. The DHP 740 may generate the provision identifier. In some examples, the provision identifier may be a randomly generated value. The third-party server identifier may identify the third-party server 750 for the DSS service. In some examples, the DHP 740 may be configured to generate the third-party server identifier, for example, during a provisioning process that was specific to the third-party' server 750.

[0125] The DHP 740 may store (e.g., in long-term memory) the provision identifier, the

DSS third-party identifier of the patient, and the third-party server identifier. These values may be stored in association with one another at the DHP 740. But, at this stage, the DHP 740 may be unaware which patient (e.g., which DHP identifier) is associated with these values.

[0126] At 712, the DHP 740 may send the provision identifier to the third-party server 750. For instance, the DHP 740 may be configured to generate a token (e.g. , a state token), where the token indicates (e.g., includes) the third-party server identifier and the provision identifier. At 712, the DHP 740 may be configured to send the token to the third-party server 750. The third-party server 750 may be configured to store (e.g., in long-term memory) the provision identifier. For example, the third-party server 750 may be configured to store the provision identifier, the third-party' server identifier, and/or the third-party patient identifier (e.g., in association with one another).

[0127] At 714, the third-party server 750 may redirect the patient (e.g. , a web browser residing on a user device associated with the patient) to an identity access management server 760. The identity access management server 760 may be configured to authenticate the identify of the patient with the DHP 740. In some examples, the identity access management server 760 may be part of the DHP 740 and/or operated by the same company. Further, the third-party server 750 may be configured to send the provision identifier (e.g, the token comprising the provision identifier) when redirecting the patient to the identity access management server 760. For instance, the third-party server 750 may send the provision identifier in a query' parameter. Additionally, in some examples, the provision identifier (e.g, the token comprising the provision identifier) may be stored within the browser’s local storage (e.g., cache memory).

[0128] At 716, the identify access management server 760 may receive the patient’s user login credentials. The user login credentials may be associated with the patient at the DHP 740. For instance, in some examples, the identify access management server 760 may request (e.g., prompt) the patient enter their user login credentials.

[0129] At 718, the DHP 740 may receive the user login credentials associated with the patient. Further, along with the user login credentials, the DHP 740 may also receive the provision identifier (e.g, the token comprising the provision identifier), which for instance, may have been stored in the patient’s browser cache by the third-party server 750 prior to redirecting the patient to the identity access management server 760.

[0130] At 720, the DHP 740 may determine the DHP identifier of the patient based on the user login credentials. For instance, the user login credentials may be associated with a particular patient in the DHP 740, and in response to receiving the correct user login credentials, the DHP 740 may determine the associated the DHP identifier of the patient. If, for instance, the user login credentials do not align with (e.g., conform to) an existing patient stored within memory of the DHP 704, the DHP 740 may stop the procedure 700 and/or redirect the patient back to the identity access management server 760 so that the patient may re-enter their user log credentials. [0131] At 722, the DHP 740 may associate the DHP identifier of the patient with the provision identifier. For example, the DHP 740 may receive the provision identifier and the user login credentials associated with the patient at 718, determine the DHP identifier of the patient based on the user login credentials at 720, and associate the DHP identifier of the patient with the provision identifier at 722. Accordingly, at 722, the DHP 740 may associate the DHP identifier of the patient with the provision identifier, the DSS third-party identifier of the patient, and/or the third-party server identifier. For instance, the DHP 740 may be configured to store (e.g., in longterm memory) the DHP identifier of the patient, the DSS third-party identifier of the patient, the provision identifier, and the third-party server identifier (e.g., store the values in association with one another). Next, in some examples, the DHP 740 may send a validation message to the third- party server 750 to, for example, provide a confirmation to the third-party server 750 that the third-party server 750 may request data from the DHP 740 relating to the patient associated with the third-party patient identifier. Accordingly, using this stored association of values, the DHP 740 may enable the third-party server 750 to request data associated with this patient.

[0132] At 724, the DHP 740 may receive a request for event data for the patient from the third-party server 750 (e.g., after provisioning the patient and third-party server 750). For example, the DHP 740 may be configured to expose a communication interface published by the DHP 740, such as a dedicated APT, that allows the third-party server 750 to request event data for patients that are part of both the third-party server 750 and the DHP 740. The request may include the third-party identifier of the patient.

[0133] At 726, the DHP 740 may determine the DHP identifier of the patient based on the provision identifier and the third-party identifier of the patient. For example, the DHP 740 may hash the third-party identifier of the patient with the hashing algorithm to generate the DSS third- party identifier of the patient. The DHP 740 may determine the DHP identifier of the patient based on the DSS third-party identifier of the patient. The DHP 740 may determine the event data associated with the patient based on the DHP identifier of the patient.

[0134] At 728, the DHP 740 may send the event data of the patient to the third-party server 750 in response to the request. In some examples, the DHP 740 may send a subset of the event data to the third-party server in response to the request. For example, as noted above, the event data may include any combination of a time of a mouthpiece cover event (e.g., the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g, which may be the same as the mouthpiece cover event, in some examples), a time and/or date of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g, an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler 730), a categorization of the inhalation by the user through the inhaler, and/or one or more inhalation parameters related to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient. For instance, the DHP 740 may send the time of the inhalation through the inhaler by the patient, the identification of the prescription type of the inhaler, and the categorization of the inhalation by the user through the inhaler at 728 (e.g., the subset of the event data).

[0135] It should be appreciated that, in some examples, the DHP 740 and the third-party server may exchange API keys prior to and/or during any of the steps described in reference to the call flow 700. For instance, the DHP 740 may be configured to generate an API key that is unique to the third-party server 750. The DHP 740 may be configured to send the API key to the third-party server 750. Further, the third-party server 750 may be configured to send the API key to the DHP 740, for example, when requesting data from the DHP 740 (e.g, at 706). Additionally, the DHP 750 may be configured to send a DHP-specific API key to the third-party server 750, for instance, when sending the provision identifier to the third-party server 750 (e.g, at 712).

[0136] Further, in some examples, the DHP 740 may determine whether the third-party server 750 is authorized to request any event data and/or is authorized to request data for the patient. For instance, the DHP 740 may be configured to determine whether the third-party server 750 has not exceeded a quota associate with an account of the third-party server. In some examples, the third-party server 750 may be associated with a quota that indicates the total number of data requests that the third-party server 750 may make (e.g, within a time period, such as one month). The DHP 740 may determine whether the third-party server 750 is authorized to request any event data, is authorized to request data for the patient, and/or has exceeded their quota, for example, prior to sending any event data for the patient to the third-party server 750. In some examples, DHP 740 may make these determinations at 706 in response to receiving the request from the third-party server 750. [0137] FIG. 8 is a block diagram that illustrates an example of a computing device 800. The computing device 800 may be an example of DHP 610 and/or the DHP 730. The computing device 800 may be an example of the third-party server 620 and/or the third-party server 750. The computing device 800 may be an example of the identity access management server 760. The computing device 800 may be an example of a user device, such as a cellphone, personal computer (PC), tablet, etc. Further, in some examples, the computing device 800 may be an example of an electronics module that is included within an inhaler, such as the inhaler 100, the inhaler 630, and/or the inhaler 730. The computing device 800 may include a processor 802, a communication interface 804, a memory 806, a display 808, input devices 810, output devices 812, and/or a GPS circuit 814. The computing device 800 may include additional, different, or fewer components, for example, based on the form factor of the computing device 800.

[0138] The processor 802 may include one or more general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, integrated circuits, a programmable logic device (PLD), application specific integrated circuits (ASICs), or the like. The processor 802 may perform signal coding, data processing, image processing, power control, input/output processing, and/or any other functionality that enables the computing device 800 to perform as described herein.

[0139] The processor 802 may store information in and/or retrieve information from the memory 804. The memory 804 may include a non-removable memory and/or a removable memory. The non-removable memory may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other ty pe of non-removable memory storage. The removable memory' may include a subscriber identity module (SIM) card, a memory stick, a memory card, or any other type of removable memory'. The memory may be local memory or remote memory external to the computing device 800. The memory 804may store instructions which are executable by the processor 802. Different information may be stored in different locations in the memory 804.

[0140] The memory 804 may comprise a computer-readable storage media or machine- readable storage media that maintains computer-executable instructions for performing one or more as described herein. For example, the memory 804 may comprise computer-executable instructions or machine-readable instructions that include one or more portions of the procedures described herein. The processor 802 of the external device 800 may access the instructions from memory for being executed to cause the processor 802 of the external device 800 to operate as described herein, or to operate one or more other devices as described herein. The memory 804 may comprise computer-executable instructions for executing configuration software. For example, the computer-executable instructions may be executed to perform, in part and/or in their entirety, one or more procedures as described herein. Further, the memory 804 may have stored thereon one or more settings and/or control parameters associated with the computing device 800.

[0141] The processor 802 that may communicate with other devices via the communication device 806. The communication device 1104 may transmit and/or receive information over a network (e.g., the network 640), which may include one or more other computing devices. The communication device 806 may perform wireless and/or wired communications. The communication device 806 may include a receiver, transmitter, transceiver, or other device capable of performing wireless communications via an antenna. The communication device 806 may be capable of communicating via one or more protocols, such as a cellular communication protocol, a Wi-Fi communication protocol, Bluetooth®, a near field communication (NFC) protocol, an internet protocol, another proprietary protocol, or any other radio frequency (RF) or communications protocol. The computing device 800 may include one or more communication devices 806.

[0142] The processor 802 may be in communication with a display 808 for providing information to a user. The information may be provided via a user interface on the display 808. The information may be provided as an image generated on the display 808. The display 808 and the processor 802 may be in two-way communication, as the display 808 may include a touchscreen device capable of receiving information from a user and providing such information to the processor 802. The processor 802 may be configured to generate, on the display 808, an indication of any event and/or dose record generated by and communication from an inhaler to the computing device 800.

[0143] The processor 802 may be in communication with a GPS circuit 814 for receiving geospatial information. The processor 802 may be capable of determining the GPS coordinates of the computing device 800 based on the geospatial information received from the GPS circuit 814. The geospatial information may be communicated to one or more other communication devices to identify the location of the computing device 800. [0144] The processor 802 may be in communication with input devices 810 and/or output devices 812. The input devices 810 may include a camera, a microphone, a keyboard or other buttons or keys, and/or other types of input devices for sending information to the processor 802. The display 808 may be a type of input device, as the display 808 may include touch-screen sensor capable of sending information to the processor 802. The output devices 812 may include speakers, indicator lights, or other output devices capable of receiving signals from the processor 802 and providing output from the computing device 800. The display 808 may be a type of output device, as the display 808 may provide images or other visual display of information received from the processor 802.

[0145] Although not illustrated, the computing device 800 may include a power supply. In some examples, the power supply may include one or more batteries. In some examples, the power supply may include an AC to DC power converter. The power supply may be configured to power the processor 802 and the other low-voltage circuitry of the computing device 800.

[0146] FIG. 9 is a flow diagram that illustrates an example procedure 900 for recording, storing, and communicating event data related to inhalation events in an inhaler system. The procedure 900 may be performed by one or more devices within an inhaler system, such as an inhaler (e.g., the inhaler 100, the inhaler 630, and/or the inhaler 730) and a DHP (e.g., the DHP 610 and/or the DHP 740). For example, a subset of the procedure 900 may be performed by the inhaler, while the remaining parts of the procedure 900 may be performed by the DHP. The procedure 900 may be performed by one or more processors (e.g., the processor 802) of the one or more components of the inhaler system. The inhaler system may perform the procedure 900 in response to a patient using their inhaler, such as when operates the inhaler (e.g, opens a mouthpiece cover of the inhaler) and inhales through the inhaler to receive a dose of medication.

[0147] The procedure 900 may begin at 910. At 912, the inhaler system (e.g., a processor of the inhaler) may record event data relating to the use of the inhaler by the patient. As described herein, the inhaler may include one or more sensors, and in response to the user’s operation of and inhalation through the inhaler, the inhaler may record event data. The event data may include any combination of a time of a mouthpiece cover event (e.g., the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g., which may be the same as the mouthpiece cover event, in some examples), a time of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g., an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler), a categorization of the inhalation by the user through the inhaler, and/or one or more inhalation parameters related to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient.

[0148] At 914, the inhaler system (e.g., the processor of the inhaler) may communicate the event data to the DHP. For example, the inhaler may be configured to communicate the event data directly or indirectly to the DHP. For example, the inhaler may be configured to communicate the event data to a user device (e.g. , a smartphone or tablet), and the user device may send the event data to the DHP. For example, the inhaler may send the event data using an encryption standard (e.g., 128-bit AES), and the user device may send the event data to the DHP. For instance, as noted above, the inhaler may include a QR code that includes an encryption key is shared between the inhaler and the user device during a pairing process, where the encryption key may be used to enable the encryption standard during the transfer of event data from the inhaler to the user device.

[0149] In some examples, the user device may transfer data (e.g. , through a public and/or private network) to the DHP using, for example, a communication interface published by the DHP, such as a dedicated API. For example, the user device may send event data relating to one or more paired inhalers to the DHP. In some examples, the user device may be configured to supplemented by the DHP with additional data and/or may be configured to analyze the event data and alter or update the event data based on computing capabilities at the user device (e.g., geo-tag the event data, determine one or more categorizations of the inhalation parameters, etc.). In other examples, the inhaler may be configured to communicate the event data directly to the DHP (e.g. , via a cellular wireless communication interface). The inhaler may be configured to communicate the event data for one or more inhalation events to the DHP in a single communication.

[0150] At 916, the DHP may be configured to store the event data (e.g., including the inhalation data) in memory at the DHP (e.g., in long-term memory). In some examples, the DHP may be configured to supplement the event data with additional data, such as PII data specific to the patient. For example, the DHP may determine the patient that is associated with the event data, and store the event data with an identifier of the patient (e.g., a patient identifier that is specific to the patient at the DHP, which may be referred to as the DHP identifier of the patient).

Further, in some examples, the DHP may be configured to associate PII with the event data (e.g., using the DHP identifier of the patient). For example, the DHP may be configured to associate the patient’s legal name (e.g, first, middle, and/or last), date of birth, and/or other PII data. Further, in some examples, the DHP may associate a username and password with the event data that, for instance, may be used by the patient to access the records at the DHP (e.g., through a web portal and/or via a user device). Accordingly, the DHP may comprise event data for a plurality of different patients, and for each patient, the DHP may comprises event data relating to a plurality of different inhalations, and the event data for a patient may be associated with the DHP identifier of the patient (e.g. , a patient identifier that is specific to the patient at the DHP). [0151] FIG. 10 is a flow diagram that illustrates an example procedure for provisioning a third-party server to enable patient data transfer from a DHP to the third-party server. The procedure 1000 may be performed by one or more devices within an inhalation system, such as a DHP (e.g, the DHP 610 and/or the DHP 740) of the inhaler system. The procedure 1000 may be performed by a processor (e.g., the processor 802) of the DHP.

[0152] The third-party server 620 may be associated with an electronic medical record (EMR) database, an Electronic Health Record (EHR) database, an electronic medical billing system, and/or the like. The third-party server 620 may include data (e.g., health data and/or PII data) related to one or more patients. The patients may be the same as and/or different from the patients that are associated with the inhalers 630 of the system 600. Similar to the DHP 610, the third-party server 620 may associate a patient with a unique identifier (e.g., alphanumeric, such as a medical record number (MRN)) that identifies the patient at the third-party server 620, which may be referred to as a third-party identifier of the patient.

[0153] As previously noted, a third-party server (e.g., the third-party server 620 and/or the third-party server 750) may not have direct access to the event data (e.g., including the inhalation data) from the inhalers of the inhaler system. The DHP may perform the procedure 1000 to allow for the transfer of event data related to one or more patients without exposing the identifier of the patient that is stored at the DHP (e.g., the DHP identifier of the patient). This functionality may be referred to as a DHP synchronization service (DSS) that is provided by the DHP. Further, the DHP may allow for the transfer of event data related to one or more patients to one or more third-party servers without exposing the DHP identifier of the patient, and also without requiring that the DHP store a third-party identifier of the patient (e.g. , in long-term memory). Since the DHP identifier of the patient and/or the third-party identifier of the patient may include and/or be used to reference PII data related to the patient, it is important that the exposure and/or storage of these identifiers be minimized. [0154] The procedure 1000 may begin at 1010. The processor may perform the procedure 1000 in response to the DHP receiving a request to transfer event data to a third-party server. At 1012, the processor may receive a request from the third-party server. The request may be to provision the third-party server (e.g., to allow the third-party server to request, at a later time, even data related to the patient) and/or the request may itself be a request for event data related to the patient. In some examples, the processor may be configured to expose a communication interface published by the DHP, such as a dedicated API, that allows the third- party server to send requests to the DHP. The request sent from the third-party server may include a third-party identifier of the patient. As noted above, the third-party server may associate the patient with a unique identifier (e.g, alphanumeric, such as an MRN) that identifies the patient at the third-party server.

[0155] At 1014, the processor may hash of the third-party identifier of the patient to generate a DSS third-party identifier of the patient. For instance, the processor may hash the third-party identifier of the patient using abashing algorithm to generate the DSS third-party identifier of the patient, for example, using a SHA-256 hash function or a SHA-512 hash function. As noted herein, the DSS third-party identifier of the patient may be an identifier that is generated by the DHP that is specific to the patient and the third-party server and used to enable the DSS service at the DHP. The processor may store the DSS third-part)' identifier of the patient, but the processor does not store the third-party identifier of the patient (e.g, in long-term memory).

[0156] At 1016, the processor may be configured to generate a provision identifier that indicates an association between the DSS third-party identifier of the patient and a third-party server identifier. As such, the provision identifier may indicate the association between the DSS third-party identifier of the patient and a third-party server identifier. In some examples, the provision identifier may be a randomly generated value. The third-party server identifier may identify the third-party server 750 for the DSS service. The processor may store (e.g., in longterm memory) the provision identifier, the DSS third-party identifier of the patient, and the third- party server identifier. These values may be stored in association with one another at the DHP. But, at this stage, the processor may be unaware which patient (e.g., which DHP identifier) is associated with these values.

[0157] At 1018, the processor may send the provision identifier to the third-party server.

For instance, the processor may be configured to generate a token (e.g. , a state token), where the token indicates (e.g., includes) the third-party server identifier and the provision identifier. For example, at 1018, the processor may be configured to send the token to the third-party server. The third-party server may be configured to store (e.g, in long-term memory) the provision identifier. For example, the third-party server may be configured to store the provision identifier, the third-party server identifier, and/or the third-party patient identifier (e.g., in association with one another).

[0158] At 1020, the processor may receive the user login credentials associated with the patient. Further, along with the user login credentials, the processor may also receive the provision identifier (e.g, the token comprising the provision identifier), which for instance, may have been stored in the patient’s browser cache by the third-party server prior to redirecting the patient to an identity access management server. For example, as noted above, the third-party server may redirect the patient (e.g, a web browser residing on a user device associated with the patient) to the identity access management server, which may authenticate the identity of the patient using the user login credentials. Further, the third-party server may send the provision (e.g, the token comprising the provision identifier) identifier in a query parameter, which may be stored within the browser’s local storage (e.g, cache memory).

[0159] At 1022, the processor may determine the DHP identifier of the patient based on the user login credentials. For instance, the user login credentials may be associated with a particular patient in the DHP, and in response to receiving the correct user login credentials, the DHP may determine the associated the DHP identifier of the patient.

[0160] At 1024, the processor may associate the DHP identifier of the patient with the provision identifier. For example, the processor may receive the provision identifier and the user login credentials associated with the patient at 1020, determine the DHP identifier of the patient based on the user login credentials at 1022, and associate the DHP identifier of the patient with the provision identifier at 1024. Accordingly, at 1024, the processor may associate the DHP identifier of the patient with the provision identifier, the DSS third-party identifier of the patient, and/or the third-party server identifier. For instance, the processor may be configured to store (e.g., in long-term memory) the DHP identifier of the patient, the DSS third-party identifier of the patient, the provision identifier, and the third-party server identifier (e.g., store the values in association with one another).

[0161] At 1026, the processor may send a validation message to the third-party server to, for example, provide a confirmation to the third-party server that the third-party server may request data from the DHP relating to the patient associated with the third-party patient identifier. Accordingly, using this stored association of values, the processor may enable the third-party server to request data associated with this patient.

[0162] FIG. 11 is a flow diagram that illustrates an example procedure for managing data transfer requesting by a DHP from a third-party server. The procedure 1100 may be performed by one or more devices within an inhalation system, such as a DHP (e.g., the DHP 610 and/or the DHP 740) of the inhaler system. The procedure 1100 may be performed by a processor (e.g., the processor 802) of the DHP. For example, the processor of the DHP may perform the procedure 1100 to provide event data related to one or more patients to one or more third-party servers without exposing the DHP identifier of the patient, and also without requiring that the DHP store a third-party identifier of the patient (e.g. , in long-term memory).

[0163] The procedure 1100 may start at 1110. At 1112, the processor may receive a request for event data for the patient from the third-party server (e.g. , after provisioning the patient and third-party server). For example, the processor may be configured to expose a communication interface published by the DHP, such as a dedicated API, that allows the third- party server to request event data for patients that are part of both the third-party server and the DHP. The request may include the third- party identifier of the patient.

[0164] At 1114, the processor may generate the DSS third-party identifier of the patient using the third-party identifier of the patient. For example, the processor may hash the third- party identifier of the patient with a hashing algorithm to generate the DSS third-party identifier of the patient, such as a SHA-256 hash function or a SHA-512 hash function.

[0165] At 11 16, the processor may determine a provision ID based on the DSS third- party identifier of the patient. For example, the processor may retrieve the provision ID from memory based on the DSS third-party ID, because the processor may have stored, during a provisioning procedure, an association between the DHP identifier of the patient, the DSS third- party identifier of the patient, the provision identifier, and the third-party server identifier.

[0166] At 1118, the processor may determine the DHP identifier of the patient based on the provision identifier, for example, using the same stored association that was generated during the provisioning procedure. The processor may determine the event data associated with the patient based on the DHP identifier of the patient.

[0167] At 1120, the processor may send the event data of the patient to the third-party server in response to the request. In some examples, the processor may send a subset of the event data to the third-party server in response to the request. For example, as noted above, the event data may include any combination of a time of a mouthpiece cover event (e.g., the movement of the mouthpiece cover from the closed position to the open position, or vice versa), a device actuation event (e.g, which may be the same as the mouthpiece cover event, in some examples), a time of the inhalation through the inhaler by the patient, an identification of the inhaler (e.g., a serial number of the inhaler), an identification of a prescription type of the inhaler (e.g., an indication of the type of medication, the total number of doses of the medication, and/or the strength of the medication delivered by the inhaler), a categorization of the inhalation by the user through the inhaler, and/or one or more inhalation parameters related to the inhalation event, such as the PIF of the inhalation through the inhaler by the patient, an inhaled volume of the inhalation through the inhaler by the patient, and a duration of the inhalation through the inhaler by the patient. For instance, the processor may send the time of the inhalation through the inhaler by the patient, the identification of the prescription ty pe of the inhaler, and the categorization of the inhalation by the user through the inhaler at 1120.

[0168] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.