System and method for identifying patient subgroups suitable for biological agents

Abstract

A system and method for determining whether a patient should receive augmentation therapy for a respiratory disorder, such as a prescription for a biologic. Usage data of a controller or a respiratory medication device for delivering a rescue respiratory medication to the patient is collected. The usage data is transmitted to a storage device. The usage data is stored in the storage device. Based on the usage data, the system determines whether the patient exceeds a first threshold level of adherence in using the respiratory medication device. Based on the usage data, the system determines whether the patient is using the rescue respiratory medication above a second threshold level. If the patient exceeds the first and second thresholds, a notification recommending augmentation therapy is provided.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the priority and benefit of U.S. Provisional Application No. 63 / 018,695, filed on May 1, 2020, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure generally relates to methods for improving the treatment of patients with potential respiratory diseases, and more specifically, to methods for determining appropriate patient subgroups for biologic therapy.

Background Art

[0003] Respiratory diseases such as asthma remain an important and costly public health problem. For example, in the United States, more than 22 million people suffer from asthma. Worldwide, the World Health Organization estimates that the population of asthma patients is 235 million and predicts an increase in the future. Similarly, in a recent study by the Centers for Disease Control and Prevention, COPD is ranked as the third leading cause of death in the United States, and nearly 15 million people may have COPD that induces impairment of lung function (A.G. Wheaton, T.J. Cunningham, E.S. Ford, J.B. Croft, "Employment and Activity Limitations Among Adults with Chronic Obstructive Pulmonary Disease - United States, 2013", MMWR Morb. Mortal Wkly. Rep., 2015, 64(11), p. 290 - 295).

[0004] Despite the development of new drugs, the hospitalization rate and the rate of emergency department visits have not decreased. In the United States, approximately 2 million people visit the emergency department annually due to asthma, 500,000 are hospitalized, and 5,000 die. Additionally, asthma is estimated to cause 5.2 million school absences and 8.7 million work absences (T. Nurmagambetov, R. Kuwahara, P. Garbe, "The Economic Burden of Asthma in the United States, 2008 - 2013", Ann. Am. Thorac. Soc., 2018, 15(3), p. 348 - 356). The total annual cost to health insurance companies and employers in the United States exceeds $82 billion (ibid.). Due to COPD, approximately 715,000 people are hospitalized annually and 134,000 die. In addition, the national cost for COPD is recently predicted to be approximately $49.9 billion, including direct medical costs of $29.5 billion, indirect morbidity costs of $8 billion, and indirect mortality costs of $12.4 billion.

[0005] Many exacerbations of asthma can be prevented with currently available treatments, yet only one in five asthma patients can control the disease. Such treatments often rely on identifying the trigger conditions of the asthmatic state and appropriately administering treatments such as medications. One mechanism for patients to self - administer medications is the inhaler. When a trigger event occurs, the patient can administer the medication through the puff from the inhaler.

[0006] The revised national guidelines require physicians to more closely monitor whether the treatments prescribed for asthma are controlling daily symptoms and improving quality of life. However, healthcare providers are limited by the availability of tools to assess how well patients are doing on a daily basis. Increasingly, many internists are beginning to use periodic written questionnaires (e.g., Asthma Control Test (ACT)) to monitor patients and determine the level of control. With these instruments, patients need to accurately recall and report the frequency of symptoms, use of medication devices (e.g., inhalers), and activity levels and limitations over a certain period, usually 2 to 4 weeks. As a result, the information collected regarding the management of respiratory diseases is subject to errors introduced by bias (e.g., false memory), different interpretations of symptoms, and behaviors (e.g., non-compliance), and the frequency of data collection is very limited such that the usefulness of the data is limited.

[0007] Standard rescue inhalants can rarely be ineffective for certain respiratory diseases. One exciting new treatment is the use of biologic agents in the respiratory space for the treatment of severe respiratory diseases, particularly asthma. Biologic agents are pharmaceuticals manufactured, extracted, or semi-synthesized in biological sources. The term "biologic agent" is used herein to refer to biology-based treatments or therapies and thus encompasses biology-based medical products or pharmaceuticals. The challenges regarding the prescription of biologic agents are that they are expensive and require either self-administration or a visit to a caregiver for administration treatment. It is also difficult to assess which type of effective biologic agent can be administered because it depends on many factors such as the number of eosinophils in the blood and sputum. Therefore, healthcare professionals are facing the challenge of administering biologic agents to the correct patient population.

[0008] There is a need for a system that enables efficient selection of patient groups to whom biologic agents are administered. There is a further need for a system that enables collection of data based on the use of controller and rescue medications for asthma in order to identify and support the approval of patient subgroups for efficient biologic agent application. During the administration of biologic agents to patients, monitoring of symptoms through the use of rescue medications and compliance with controller medications is also needed.

Summary of the Invention

Means for Solving the Problems

[0009] One example disclosed is a system for determining the suitability of enhanced treatment for respiratory diseases. The system includes a communication interface for collecting usage data of a respiratory drug device and delivering a controller or rescue respiratory drug to a patient. The system includes a memory device for storing the collected usage data. A data analysis module is operable to determine, based on the collected usage data, whether the patient is exceeding a first threshold level of compliance in the use of the respiratory drug device. The module determines, based on the collected usage data, whether the patient is using a rescue respiratory drug in excess of a second threshold level. The module provides a notification recommending enhanced treatment if the patient exceeds the first and second thresholds.

[0010] A further implementation form of the exemplary system is when the respiratory disease is asthma. Another implementation form is when the enhanced treatment is a prescription of a biologically based treatment or therapy. Another implementation form is when the first threshold is a compliance rate of at least about 65% compliance, such as at least about 70%, 75%, 80%, or 85% compliance. In one implementation form, the first threshold is a compliance rate of at least about 75%. Another implementation form is when the second threshold is at least about 15 uses of a rescue medication over a week, such as at least about 22 or 28 uses of a rescue medication over a week. In one implementation form, the second threshold is at least about 28 uses of a rescue medication over a week. Another implementation form is when the system includes a mobile computing device, and the mobile computing device is communicating with a memory device and a communication interface. Another implementation form is when the mobile computing device includes an application that assists in the application of the enhanced treatment to the patient. Another implementation form is when the notification is provided electronically to one of the patient, a caregiver, or a healthcare provider. Another implementation form is when the system includes an enhanced treatment module engine that is communicating with the mobile computing device. The enhanced treatment module is operable to track the use of the enhanced treatment by the patient. Another implementation form is when the enhanced treatment module is operable to direct additional enhanced treatment to the patient. Another implementation form is when the enhanced treatment is a prescription of an injectable biologic. The application includes an interface for instructing the patient about at least one injection technique. Another implementation form is when the interface includes an interface for recording the injection area of the biologic. Another implementation form is when the system includes a health monitor for monitoring the patient. The data analysis module collects data from the health monitor to determine the patient's response to the enhanced treatment.

[0011] Another disclosed example is a method for determining whether a patient should receive enhanced treatment for a respiratory disease. Usage data of a controller or a respiratory drug device for delivering a rescue breathing drug to a patient is collected via a communication interface. The usage data is transmitted to a memory device. The usage data is stored in a memory device accessible to a data analysis module. In the use of the respiratory drug device, it is determined based on the collected usage data whether the patient is exceeding a first threshold level of compliance. It is determined based on the collected usage data whether the patient is using a rescue breathing drug beyond a second threshold level. If the patient exceeds the first threshold and the second threshold, a notification recommending enhanced treatment is provided.

[0012] Further implementation forms of the exemplary method are when the respiratory disease is asthma. Another implementation form is when the enhanced treatment is a prescription of a biologically based treatment or therapy. Another implementation form is when the first threshold is a compliance rate of at least about 65% compliance, such as at least about 70%, 75%, 80%, or 85% compliance. In one implementation form, the first threshold is a compliance rate of at least about 75%. Another implementation form is when the second threshold is at least about 15 uses of a rescue medication over a week, such as at least about 22 or 28 uses of a rescue medication over a week. In one implementation form, the second threshold is at least about 28 uses of a rescue medication over a week. Another implementation form is when the method includes establishing communication to a mobile computing device having a memory device and a communication interface. Another implementation form is when the mobile computing device includes an application that assists in the application of the enhanced treatment to the patient. Another implementation form is when the notification is provided electronically to one of the patient, a caregiver, or a healthcare provider. Another implementation form is when the method includes tracking the use of the enhanced treatment by the patient. Another implementation form is when the enhanced treatment module is operable to direct additional enhanced treatment to the patient. Another implementation form is when the enhanced treatment is a prescription of an injectable biologic. The application includes an interface for instructing the patient about at least one injection technique. Another implementation form is when the interface includes an interface for recording the injection area of the biologic. Another implementation form is when the method includes monitoring the patient via a health monitor for monitoring the patient. The method also includes collecting data from the health monitor to determine the patient's response to the enhanced treatment.

[0013] The above summary is not intended to represent every embodiment or all aspects of the present disclosure. Rather, the foregoing summary merely provides some examples of novel aspects and features described herein. The above features and advantages of the present disclosure, as well as other features and advantages, will be readily apparent from the following detailed description of representative embodiments and modes for carrying out the invention when taken in connection with the accompanying drawings and the appended claims.

[0014] The present disclosure will be better understood from the following description of exemplary embodiments, taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The present disclosure is capable of various modifications and alternative forms. Some representative embodiments are shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the present invention is not intended to be limited to the particular forms disclosed. Rather, the present disclosure encompasses all modifications, equivalents, and alternatives within the spirit and scope of the present invention as defined by the appended claims.

[0017] The present invention may be embodied in many different forms. Representative embodiments will be shown in the drawings and will be described in detail herein. The present disclosure is an example or illustration of the principles of the present disclosure and is not intended to limit the embodiments showing the broad aspects of the present disclosure. To that extent, for example, elements and limitations disclosed in sections such as the abstract, summary of the invention, and detailed description of the invention but not explicitly recited in the claims should not be incorporated into the claims singly or collectively by implication, inference, or other means. For the purposes of this detailed description, unless otherwise specified, the singular form includes the plural form and vice versa. Also, the word "comprising" means "including without limitation". Further, approximate words such as "about", "almost", "substantially", "approximately", etc. may be used herein to mean "to", "near to", or "substantially near to", or, for example, "within 3 - 5% of", or "within acceptable manufacturing tolerances", or any logical combination thereof.

[0018] The present disclosure relates to a system for collecting data regarding the use of rescue inhalers and patterns of individual - level controller drug compliance. The data may be used to identify and explain subgroups of patients with respiratory diseases such as asthma for potential involvement with biologic therapies. Such subgroups of patients may include patients who require additional treatment beyond rescue medications and patients who are most likely to comply with the prescribed biologic therapy.

[0019] FIG. 1 shows a respiratory disease analysis system 100 according to one embodiment for monitoring accurate real-time drug device events, performing analysis on the data thereof, and providing a respiratory disease exacerbation risk notification based on the identification of triggers for primary patients related to the general patient population. Such a respiratory disease may be an asthma event that can be addressed through rapid treatment with a drug by an inhaler.

[0020] The respiratory disease analysis system includes a client computing device 110, a drug device sensor 120, a drug device 160, an application server 130, a database server 140, and a network 150. Other servers such as a healthcare provider server 170 and a pharmaceutical supply server 180 may be coupled to the network 150. FIG. 1 shows only the case where most components of the respiratory disease analysis system 100 are single, but in reality, there may be two or more of each component, and additional or fewer components may be used.

[0021] Client device 110 interacts with the respiratory disease analysis system 100 via network 150 in response to requests from its users. For purposes of explanation and clarity, it is useful to identify at least two different types of users. Patient 111 is a user suffering from a respiratory disease such as asthma who uses the respiratory disease analysis system 100 at least in part to obtain notifications of personalized rescue event risks provided by server 130 and administrative notifications created in this example by healthcare provider 112. Patient 111 may be assisted by a caregiver who is an additional or alternative user. The caregiver may receive the same notifications as patient 111 (not shown in FIG. 1), or may have their own application 115 and client device 110 that receives notifications on behalf of the patient (e.g., a parent / guardian of patient 111 who may desire their own client device 110 to receive notifications in different events than their child's). Such notifications may be provided in exchange for the user's permission to enable the respiratory disease analysis system 100 to monitor the use of the patient 111's drug device 160. As described below, drug events are detected by sensors 120 associated with drug device 160 and the user's client device 110, then reported to application server 130, and then a process may be initiated to generate risk notifications provided to the user through client device 110. In this example, patient 111 represents a population of patients for which individual data is obtained for each patient in the group.

[0022] Another type of user is healthcare provider 112 who also receives, with the explicit permission of patient 111, notifications regarding the patient's asthma management, as well as aggregated asthma community rescue event data and derived statistics regarding asthma events and other related data. Other types of users may be contemplated.

[0023] The client device 110 is a computer system that can be a portable computing device such as a smartphone, tablet, or laptop. The client device 110 may also be a television (e.g., a smart connected television) or a speaker system (e.g., a smart connected speaker). Exemplary physical implementations are described more fully below with respect to FIG. 2. The client device 110 is configured to wirelessly communicate with the respiratory disease analysis system 100 via the network 150. When accessing the network 150, the client device 110 transmits to the system 100 both the time of the drug usage event and information describing the event received from the associated drug device sensor 120 (referred to throughout as "sensor 120"). The geographical location of the user may also be transmitted to the respiratory disease analysis system 100.

[0024] With respect to the user's location and the time of the event, the client device 110 may determine the geographical location and time of the rescue event using information about the cellular or wireless network 150 to which it is connected. For example, the current geographical location of the client device 110 may be determined by querying directly the software stack providing the network 150 connection. Alternatively, the geographical location information may be obtained by performing a ping to an external web service (not shown in FIG. 1) made accessible via the network 150. The time of the event may be provided by the sensor 120 as part of the event data or added to the event data by querying appropriate software routines available as part of the client device's native operating system.

[0025] In addition to communicating with the application server 130, the client device 110 wirelessly connected to the respiratory disease analysis system 100 may exchange information with other connected client devices 110. For example, through the client software application 115, a healthcare provider 112 or caregiver may receive a risk deterioration notice describing a recent rescue event regarding the patient 111 and, in response, send advice to the patient 111 for treatment after an asthma rescue event. Similarly, through the application 115, the patient 111 may communicate with the healthcare provider 112 and other patients 111, or caregivers.

[0026] The application 115 is displayed on the screen of the client device 110 and provides a user interface (referred to herein as a "dashboard") that allows a user to input commands to control the operation of the application 115. The dashboard is a mechanism by which the healthcare provider 112, caregiver, and patient 111 access the respiratory disease analysis system 100. For example, the dashboard enables the patient 111, caregiver, and provider 112 to interact with each other, receive asthma rescue event risk notifications, exchange messages regarding treatment, and provide and receive additional event and non-event data. The application 115 may be coded as a web page, a series of web pages, or content, or alternatively, may be coded to render within an internet browser. The application 115 may be coded as a dedicated application configured to operate on the native operating system of the client device 110.

[0027] In addition to providing the dashboard, application 115 may perform some data processing locally on the asthma rescue event data using the resources of client device 110 before sending the processed data through network 150. The event data sent through network 150 is received by application server 130, which analyzes and processes it for storage and retrieval in cooperation with database server 140. Application server 130 may instruct database server 140 with search and storage requests when requested by client application 115. As described, this analysis may be extended to include event data from multiple patients 111.

[0028] Client device 110 communicates with sensor 120 using a network adapter and either a wired or wireless communication protocol, for example, the Bluetooth (R) Low Energy (BTLE) protocol as an example. BTLE is a short-range, low-power protocol standard that wirelessly transmits data over the radio link of a short-range wireless network. After sensor 120 and client device 110 are paired with each other using a BTLE passkey, sensor 120 automatically synchronizes and communicates information regarding the use of the client device 110 and the drug device. If sensor 120 is not paired with client device 110 prior to a rescue drug event, the information is stored locally until such pairing occurs. Upon pairing, sensor 120 communicates the stored event records to client device 110. In other implementations, other types of wireless connections are used (e.g., infrared or IEEE802.11).

[0029] Although the client device 110 and the drug device 160 have been described above as separate physical devices (such as a smartphone and an inhaler, respectively), in the future, the drug device 160 may be considered to include not only the sensor 120 integrated into a single housing together with the drug device 160, but also aspects of the client device 110. For example, the drug device 160 may include an audiovisual interface that includes not only a speaker, but also a display or other lighting element to present visual and audible information. In such an implementation, the drug device 160 itself may directly present the content of the notifications provided by the server 130 instead of, or in addition to, presenting them through the client device 110.

[0030] The drug device 160 is a medical device used to deliver a drug to the lungs of a user who has experienced a rescue event for a respiratory disease. Various drugs are used for asthma. The various drugs may also be used for asthma rescue and control. Drug devices (e.g., inhalers) are typically portable and small enough to be carried by hand for easy access when treating a respiratory attack. In one embodiment, the drug is delivered in aerosol form through a drug device 160 such as a metered-dose inhaler. The metered-dose inhaler includes a pressurized propellant canister for the aerosol drug, a metering valve for delivering a calibrated dose of the drug, and a plastic holder that holds the pressurized canister and forms a mouthpiece for drug delivery. In another embodiment, the drug is delivered in dry powder form through a drug device 160 such as a dry powder inhaler. The dry powder inhaler may have a Cartesian oval body that houses a wheel and gear mechanism that allows the user to index through a strip of dry powder drug. The body of the dry powder inhaler also includes a manifold and a mouthpiece for delivering the dry powder to the user. Examples of controller drugs dispensed by the controller drug device 160 include beclomethasone dipropionate, beclomethasone dipropionate HFA budesonide, ciclesonide, flunisolide, fluticasone furoate, fluticasone propionate, mometasone, mometasone furoate HFA 100 or 200 mcg, and triamcinolone acetonide, as well as combinations of these drugs with a long-acting bronchodilator such as salmeterol or formoterol. Other drugs may include long-acting beta-agonists (LABAs) such as albuterol sulfate, formoterol fumarate, salmeterol xinafoate, arformoterol tartrate, olodaterol.Long-acting beta agonists may include combinations such as budesonide in combination with formoterol; fluticasone furoate, umeclidinium, and vilanterol; fluticasone propionate and salmeterol; fluticasone furoate 100 mcg and vilanterol 25 mcg; glycopyrrolate / formoterol fumarate; indacaterol / glycopyrrolate; mometasone in combination with formoterol; tiotropium 2.5 mcg and olodaterol 2.5 mcg; and combinations such as umeclidinium and vilanterol. Examples of rescue medications dispensed by the rescue medication device 160 may include albuterol sulfate, albuterol sulfate HFA, albuterol sulfate inhalation and spray solution, salbutamol, levalbuterol HCl, metaproterenol, and terbutaline.

[0031] Each patient may be associated with two or more medication devices 160. For example, a patient may have a rescue medication device 160 that dispenses a rescue medication and a controller medication device 160 that dispenses a controller medication. Similarly, each patient may be associated with two or more sensors 120, each selected to operate with one of the patient's medication devices 160.

[0032] Generally, the sensor 120 is a physical device that monitors the use of the medication device 160. The sensor 120 is removably attachable to the medication device without interfering with the operation of the medication device, or the sensor 120 is an integrated component that is an original part of the medication device 160 made available by its manufacturer.

[0033] Sensor 120 includes its own network adapter (not shown) that communicates with client device 110 through a wired connection or, more typically, through a wireless radio frequency connection. In one embodiment, the network adapter is a Bluetooth (R) Low Energy (BTLE) wireless transmitter, although in other embodiments, other types of wireless communication (e.g., infrared, IEEE 802.11) may be used.

[0034] Sensor 120 may be configured to communicate more directly with application server 130 to transmit the collected data. For example, if the network adapter of sensor 120 is configured to communicate via a wireless standard such as IEEE 802.11 or LTE, the adapter may exchange data with a wireless access point such as a wireless router and then communicate with application server 130 without necessarily involving client device 110 each time data is exchanged. These two communication methods are not mutually exclusive, and sensor 120 may be configured to communicate with both client device 110 and application server 130, for example, using redundant transmission to ensure that event data arrives at application server 130 while the application server 130 is determining what notifications to provide in response to an event, or to directly transmit information to client device 110.

[0035] As introduced above, sensor 120 captures data regarding the use of drug device 160. Specifically, each sensor 120 captures the time and geographical location of a rescue drug event by patient 111, i.e., the use of rescue drug device 160. Each sensor 120 automatically transmits event data in real time or as soon as a network connection is achieved without input from patient 111, caregiver, or healthcare provider 112. The drug event information is transmitted to application server 130 for use in analysis, generation of asthma rescue event notifications, and aggregated analysis of event data across multiple patients.

[0036] To achieve this goal, there are many different ways to configure the sensor 120, and in part, the configuration depends on the configuration of the drug device 160 itself. Generally, all sensors 120 include an on-board processor, a persistent memory, and the network adapter described above, which together function to record, store, and report drug event information to the client device 110 and / or the server 130. The sensor 120 may also include a clock for recording the date and time of an event.

[0037] Regarding the specific configuration of the sensor 120, since conventional inhalers such as mechanical dose counters are not designed with the sensor 120 in mind, the sensor 120 may be configured accordingly. Some implementations in this form include mechanical, electrical, or optical sensors for detecting the movement of the device 160, priming of the device, activation of the device, inhalation by the user, etc. In contrast, modern inhalers such as dose counters with deflectable membranes include electrical circuitry that can report event information as electrical data signals designed to be received and interpreted by the sensor 120. For example, the drug device 160 itself can report movement, priming, and activation to the sensor 120.

[0038] Detailed information regarding the hardware and software components of the sensor 120 and the drug device 160, and their interaction for recording rescue drug events, can be found in U.S. Patent Application No. 12 / 348,424, filed on January 1, 2009, and International Application No. PCT / US2014 / 039014, filed on May 21, 2014, both of which are hereby incorporated by reference in their entireties.

[0039] The application server 130 is a computer or a network of computers. Although a simplified example is shown in FIG. 2, typically, an application server is a server-class system that uses a powerful processor, a large amount of memory, and faster network components as compared to a typical computing system used as a client device 110, for example. The server typically has large-scale secondary storage, for example, by using an array of RAID (Redundant Array of Independent Disks) and / or by establishing a relationship with an independent content delivery network (CDN) that has contracted to store, exchange, and transmit data such as the wheezing notifications considered above. In addition, the computing system includes an operating system, for example, a UNIX (registered trademark) operating system, a LINUX (registered trademark) operating system, or a WINDOWS (registered trademark) operating system. The operating system manages the hardware and software resources of the application server 130 and provides various services such as process management, data input / output, and peripheral device management. The operating system provides various functions for managing files stored on the device, for example, creating new files, moving or copying files, and transferring files to a remote system.

[0040] Since the application server 130 includes a software architecture for assisting access to and use of the analysis system 100 by many different client devices 110 through the network 150, at a high level, it can generally be characterized as a cloud-based system. The application server 130 generally provides a platform for patients 111 and healthcare providers 112 to report data recorded by sensors associated with their drug devices 160, including both rescue drug events and controller drug events, cooperate on a respiratory disease treatment plan, view and obtain information related to their status and geographical location, and utilize various other functions.

[0041] Generally, application server 130 is designed to handle a wide variety of data. Application server 130 includes a logical routine that performs various functions, including checking the validity of incoming data, parsing and formatting the data as necessary, passing the processed data to database server 140 for storage, and verifying that database server 140 has been updated.

[0042] Application server 130 stores and manages data at least partially on a per-patient basis. For this purpose, application server 130 creates a patient profile for each user. A patient profile is a set of data that characterizes patient 111 of respiratory disease analysis system 100. The patient profile may include identifying information about the patient, such as age, gender, current rescue medications, current controller medications, notification settings, a compliance plan for the controller medications, relevant medical history, and a list of non-patient users authorized access to the patient profile. The profile may further specify a unique media access control (MAC) address or other device identifier that identifies one or more client devices 110 or sensors 120 that are authorized to submit the patient's data (such as events for controller and rescue medications).

[0043] The profile may specify which different types of notifications are provided to patient 111 or a caregiver, and their personal healthcare provider 112, as well as how often the notifications are provided. For example, patient 111 or a caregiver may permit healthcare provider 112 to receive notifications indicating a rescue event. Patient 111 or a caregiver may also permit their healthcare provider 112 to be given access to their patient profile and rescue event history. If healthcare provider 112 is provided access to patient 111's patient profile, the healthcare provider may specify a compliance plan for the controller or a medication schedule for the rescue medications for the corresponding asthma condition. The medication schedule may include the prescribed number of daily administrations of the controller medication.

[0044] The application server 130 also creates a profile of the healthcare provider 112. The healthcare provider profile may include the identification of information about the healthcare provider 112, such as the office location, qualifications, and certifications. The healthcare provider profile also includes information about the patient population. The provider profile may also include access to all of the profiles of that provider's patients, as well as access to aggregated demographic information and data derived from those profiles, such as the event patterns of rescue and controller medications. This data may be further subdivided according to any type of data stored in the patient profiles, such as by geographical area (e.g., neighborhood, city) and over time periods (e.g., weekly, monthly, or annually).

[0045] The application server 130 receives rescue medication event information from the client device 110 or the sensor 120 and triggers various routines on the application server 130. In the exemplary implementation described below, the data analysis module 131 accesses respiratory disease event data and other data including the patient's profile, analyzes the data, and executes routines for outputting the analysis results to both the patient 111 or caregiver and the provider 112. This process is generally referred to as a risk analysis of respiratory diseases. In this example, a risk analysis is performed in relation to the asthma of patient 111. The asthma risk analysis may be performed at any time in response to a rescue event, due to a relevant change in the patient's environment, and in response to any one of a number of trigger conditions discussed further below.

[0046] Other analyses are also possible. For example, risk analysis may be performed for the use of rescue and controller medications for a plurality of patients identified based on spatial / temporal clusters (or outbreaks) of drug use based on personal, geographical, clinical, epidemiological, demographic, or spatial or temporal baselines, or historical permutations from predicted or expected values. Other types of analysis may include daily / weekly compliance trends, changes in compliance over time, comparison of compliance with other relevant groups (e.g., all patients, patients taking a particular rescue drug or controller drug or combinations thereof), identification of triggers (spatial, temporal, environmental), trends in rescue use over time, and comparison of rescue use with other relevant groups. Thus, the compliance rate for a particular patient is calculated by dividing the number of puffs of the controller taken on a particular day by the number of puffs prescribed per day. This daily metric is averaged over a particular period to obtain the average daily compliance. The number of puffs of the prescribed controller is based on the patient's medication plan entered into the application.

[0047] In response to any analysis performed, the application server 130 prepares and distributes push notifications to transmit to the patient 111, the authorized healthcare provider 112, and / or other users provided access to the patient's profile, such as a caregiver. The notification may provide details regarding the timing, location, and patient 111 affected in a drug rescue event. The notification may additionally include a distress signal or emergency signal requesting emergency assistance to be distributed to the emergency support provider 112. The notification may also include the results of the asthma risk analysis performed by the data analysis module 131. Details regarding the types of notifications that may be transmitted and the content that may be included in the notification are further described below.

[0048] In addition to providing push notifications in response to asthma risk analysis, notifications may be provided as pull notifications at specific time intervals. Additionally, some notifications (push or pull) may be triggered in response to a risk analysis performed in response to an event of a rescue medication, not so as to guarantee an updated notification, but instead may be triggered in response to a risk analysis performed in response to one of the underlying factors of a change in asthma risk analysis. For example, if weather conditions indicate that an increase in air pollution is occurring or is imminent, it may trigger the performance of an asthma risk analysis for all patients in a specific geographic area where the pollution is occurring.

[0049] The notifications are provided to the client application 115 through the network 150 in a data format specially designed for use in the client application and additionally or alternatively may be provided in other data formats communicated using a Short Message Service (SMS) message, an email, a phone call, or other communication medium.

[0050] The database server 140 stores relevant data of patients and providers such as profiles, medication events, patient medical histories (e.g., electronic medical records). The patient and provider data are encrypted for security, protected at least by passwords, and otherwise protected to meet the requirements of the Health Insurance Portability and Accountability Act (HIPAA). Data from multiple patients (e.g., aggregated rescue medication event data) are incorporated, and all analyses provided to the user (e.g., asthma risk analysis) are anonymized such that information identifying individuals is removed to protect patient privacy.

[0051] The database server 140 also stores non-patient data used in asthma risk analysis. This data includes regional data on many geographical areas, such as public spaces in residential or commercial areas where patients are physically located and can be exposed to pollutants. This data may specifically include, or be processed to obtain, the proximity of patients to green spaces (areas where trees and plants are concentrated). An example of regional data includes meteorological data containing geographical information, such as temperature, wind patterns, humidity, air quality index, etc. Another example is pollution data containing geographical information, including the number of particles of various pollutants measured at a certain point in time or empirically. Regional data includes information on current weather conditions at the time and place of rescue events, such as temperature, humidity, air quality index, etc. All items of the above data can change over time and the data itself can be indexed over time. For example, individual data points may be available for each time of day (including by minute or hour), or over longer periods such as daily, weekly, monthly, or seasonally. Although the database server 140 is shown as a separate entity from the application server 130 in FIG. 1, the database server 140 may instead be part of another server, such as server 130, such that the database server 140 is implemented as one or more persistent storage devices and has a software application layer for interfacing with data stored in a database that is part of another server 130, and may be a hardware component.

[0052] The database server 140 stores data according to a defined database schema. Typically, data storage schemas between different data sources can vary significantly due to differences in the implementation form of the underlying database structure, even when storing the same type of data, including event logs and log metrics of cloud applications. The database server 140 can also store different types of data, such as structured data, unstructured data, or semi-structured data. The data of the database server 140 may be associated with patients, groups of patients, and / or entities. The database server 140 manages database objects represented by the database server 140 and provides support for database queries in a query language (e.g., SQL for relational databases, JSON NoSQL databases, etc.) to specify commands to read information from or write to the database server 140.

[0053] Network 150 represents various wired and wireless communication paths among client device 110, sensor 120, application server 130, and database server 140. Network 150 uses standard Internet communication technologies and / or protocols. Thus, network 150 may include links using technologies such as Ethernet®, IEEE 802.11, Integrated Services Digital Network (ISDN), Asynchronous Transfer Mode (ATM), etc. Similarly, the networking protocols used on network 150 may include Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), etc. The data exchanged on network 150 may be represented using technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), etc. Also, all or some of the links may be encrypted using conventional encryption technologies such as Secure Sockets Layer (SSL), Secure HTTP (HTTPS), Virtual Private Network (VPN), etc. In another embodiment, an entity may use custom and / or proprietary data communication technologies instead of, or in addition to, those described above.

[0054] FIG. 2 is a high-level block diagram according to one embodiment showing the physical components of an exemplary computer 200 that can be used as part of the client device 110, application server 130, and / or database server 140 of FIG. 1. Illustrated is a chipset 210 coupled to at least one processor 205. Coupled to the chipset 210 are a volatile memory 215, a network adapter 220, an input / output (I / O) device 225, a storage device 230 representing non-volatile memory, and a display 235. In one embodiment, the functions of the chipset 210 are provided by a memory controller 211 and an I / O controller 212. In another embodiment, the memory 215 is directly coupled to the processor 205 instead of the chipset 210. In some embodiments, the memory 215 includes high-speed random access memory (RAM) such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices.

[0055] The storage device 230 is any non-transitory computer-readable storage medium such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. The memory 215 holds instructions and data used by the processor 205. The I / O device 225 may be a touch input surface (capacitive or otherwise), a mouse, a trackball, or other type of pointing device, a keyboard, or another form of input device. The display 235 displays images and other information from the computer 200. The network adapter 220 couples the computer 200 to the network 150.

[0056] As is known in the art, computer 200 may have components different from and / or additional to those shown in FIG. 2. Also, computer 200 may lack certain illustrated components. In one embodiment, computer 200 functioning as server 140 may lack dedicated I / O device 225 and / or display 218. Further, storage device 230 may be local and / or remote from computer 200 (such as being embodied within a storage area network (SAN)), and in one embodiment, storage device 230 is not a CD-ROM device or a DVD device.

[0057] Generally, the exact physical components used in client device 110 differ in size, power requirements, and performance from those used in application server 130 and database server 140. For example, client device 110, which is often a home computer, tablet computer, laptop computer, or smartphone, includes a relatively small storage capacity and processing power, but includes input devices and a display. These components are suitable for user input of data and reception, display, and interaction with notifications provided by application server 130. In contrast, application server 130 may include a number of physically separate locally networked computers, each having a significant amount of processing power for performing the wheezing risk analysis introduced above. In one embodiment, the processing power of application server 130 is provided by a service such as Amazon Web Services (trademark). In contrast, database server 140 may include a number of physically separate computers, each having a significant amount of persistent storage capacity for storing data associated with the application server.

[0058] As is known in the art, computer 200 is adapted to execute computer program modules that provide the functions described herein. The modules can be implemented in hardware, firmware, and / or software. In one embodiment, the program modules are stored in storage device 230, loaded into memory 215, and executed by processor 205.

[0059] In this example, an application running on application server 130 can collect data such as usage data from a drug device such as device 160 of FIG. 1. This application can be used to collect data from the use of drug devices by a patient population to identify patients having a moderate / severe respiratory disease such as asthma that may be eligible for biologic therapy. Suitable biologic therapies may include, for example, omalizumab (Xolair), mepolizumab (Nucala), reslizumab (Cinqair), benralizumab (Fasenra), and dupilumab (Dupixent).

[0060] For example, the data collected may be used to determine factors such as a) use of an inhaled corticosteroid (ICS) or bronchodilator such as a LABA; b) proof of ICS / LABA use; c) proof of controller compliance. Additional inhaled corticosteroid data related to asthma control may be analyzed. Such data related to asthma may include use of a rescue inhaler, nocturnal symptoms, asthma control score (ACT) by ACT, asthma control by ACT, and readings from external sensors such as spirometry readings.

[0061] Figure 3 is a graph 300 of the breakdown of potential patients based on collected usage data of drug devices such as control inhalers and rescue inhalers. As described herein, the usage data may be collected by the analysis system 100 of FIG. 1. In this example, the first bar 310 represents all patients. Bar 310 is divided into patients with associated controller drug data 312 and patients 314 for whom controller drug data is not available. The second bar 320 represents the selection of patients with controller drug data 312. These patients are divided into patients 322 who comply with the drug instructions of the controller by 75% or more and patients 324 with a compliance rate of less than 75%. Of course, other thresholds may be used to separate the patient population. For example, any suitable threshold may be selected from a compliance of about 65% or more. For example, a threshold between 65% and 85% may be used. Such values may be a compliance of at least about 65%, 70%, 80%, or 85%. In this example, patient data for 2 to 3 months (e.g., 60 days or 90 days) is collected to determine the threshold, but longer or shorter periods may be used.

[0062] The third bar 330 represents a first group 332 of patients for whom no rescue event has been reported, a second group 334 of patients with a specific threshold less than, such as less than 28 puffs per week for a rescue event, and a third group 336 of patients with high rescue use. Other thresholds for rescue use may be used, such as any threshold above 15 uses of the rescue drug over a one-week period. For example, such values may range between 15 and 28 uses, such as 15 or 22 uses of the rescue drug over a one-week period. In this example, the first group 332 of patients and the second group 334 of patients should continue with the rescue drug prescription therapy. The third group of patients 336 may be considered for biologics treatment recommendations.

[0063] In this example, the system 100 of FIG. 1 may be used to notify a user, their caregiver, and clinician, via a healthcare system including a healthcare provider server 370, that a patient may be a suitable candidate for a biologic based on the collected data described above. As described above, since the collected data is the same as the data that must be collected by the provider to justify the prescription of a biologic, the system may retain the collected data and make it available to candidate patients for a biologic to streamline the application process. Such data may include documentation of ICS / long-acting beta agonist (LABA) use; documentation of lack of disease management; history of exacerbations; and documentation of response / improvement to treatment.

[0064] FIG. 4 shows screen images of an exemplary pre-authorization form 400 and an exemplary respiratory disease report 450 that may be generated from patient data and usage data collected by the system 100. The pre-authorization form 400 includes data that may be pre-populated from data collected by the system 100 to streamline the application process for enhanced treatment.

[0065] In this example, the respiratory disease report 450 may be used to document the prescription of enhanced treatment for asthma. The respiratory disease report 450 includes a patient details field 460, a health status field 470, and a medication usage field 490. The patient details field 460 includes information about the patient and the type of medication currently prescribed. The health status field 470 includes a control status graph 472, a nocturnal rescue usage data field 474, a controller compliance field 476, a rescue trend graphic 478, and an asthma control test results field 480. The control status graph 472 in this example provides a graph showing the percentage of asthma states that are well controlled, not well controlled, and inadequately controlled over a predetermined period such as 30 days. The nocturnal rescue usage data field 474 indicates the number of nights over a predetermined period during which the patient required rescue use of an inhaler. The controller compliance field 476 indicates the percentage of compliance with the use of an inhaler over a predetermined period. The rescue trend graphic 478 shows different graphics indicating the time of rescue use and the day of the week of rescue use. The asthma control test results field 480 indicates the results of an asthma control test.

[0066] The medication usage field 490 includes a rescue medication usage graph 492 showing the days on which rescue medication use occurred during a predetermined period, as well as the number of times during the night and the total number of times during a particular day. The medication usage field 490 also includes a controller medication usage graph 494 showing compliance with different controller medications.

[0067] When a biologic is prescribed, the system 100 may continue to monitor the use of such biologic via an application executed on the patient computing device 110 of FIG. 1. The system 100 may also provide reminders to the patient, i.e., to encourage compliance, based on a medication treatment plan. The system 100 may also provide useful information such as providing a user interface that includes visual or written instructions for entering the injection site and guiding them through the steps of the injection.

[0068] Such an application may include a dashboard interface that enables a patient to enter that they have taken a biologic as part of their enhanced treatment. The interface may also collect patient-reported outcomes from the administration of the biologic. This data may be reported to the application server 130 along with prescription and dispensing information from the pharmaceutical supply server 180 to track the biologic for a particular patient. An application running on the patient computing device 110 may be adapted for a particular use of the biologic, thereby providing unique content of the biologic that helps the user understand how to administer the biologic, educational content that helps the user better understand the benefits of the biologic, and educational content that helps the user better understand their asthma.

[0069] FIG. 5 shows a screen image of an interface generated by an exemplary application executed on patient computing device 110 to report an injection of a biologic. Injection interface 500 shows a location graph 502 representing areas on the body graphic where an injection can be made. When the patient selects an appropriate area, a confirmation message 504 indicating that the injection has been recorded and the location of the injection is displayed. The recent site interface 510 shows a body graphic 512 indicating the location of recent and predicted future injections. The application may display instructions on how the injection is to be performed and / or provide voice instructions. Summary table 514 enumerates the most recent injections by date and body location, as well as the next scheduled injection. Confirmation interface 520 provides a button 522 that enables the patient to confirm that the reported injection has been made. The application may include a reminder function to remind the patient of when to inject the biologic, and may include features such as a pop-up window or a countdown clock. The application may include an interface that enables the user to select a biologic and set the schedule for injecting the biologic and the corresponding reminders. The application may include trend graphics showing the historical record of previous injections. Such a historical record may be incorporated into other patient data such as ACT history or inhaler dosages. The application may enable the user to further obtain details such as body location, time, and the drug of past injections. The application may also include an interface with educational information regarding treatments such as respiratory diseases and specific biologics. System 100 may receive data from the application, track injection sites, and make recommendations for future injections based on the historical data. System 100 may analyze data received from the application regarding past trends and infer events such as exacerbations.

[0070] System 100 may be used to rationalize the reordering of biological agents and provide reminders to reorder medications. System 100 may track delivery status to improve medication fulfillment and compliance. Usage data and other patient data may be sent to a pharmaceutical distribution system that may include a pharmaceutical supply server 180. Patient tracking and biologic usage can send notifications to patients, caregivers, healthcare providers, or other relevant parties to predict the reordering of biologic agents.

[0071] Patient-reported outcomes (PRO) and sensor data collected by System 100 can be used to measure and possibly predict responsiveness to specific biologic agents. Examples of patient-reported outcomes useful in asthma treatment can include eosinophil count in the blood, FeNO, allergen-induced symptoms, childhood-onset asthma, exacerbations in previous periods, adult-onset asthma, nasal polyposis, and mild / moderate atopic dermatitis. If the data suggest a non-significant response to the prescribed biologic agent, the system may recommend a change to another biologic agent after a given time. System 100 can also analyze / identify subgroups of patients who are most responsive to different biologic agents. Responses to biologic agents can be based on inhaler use and / or associated with other sensor data, such as respiratory rate, heart rate, bronchoconstriction, or exhaled biomarkers. Thus, data may be collected through sensors that may include rescue inhaler use reported by the sensor, nocturnal awakenings reported by the sensor, and sensor-derived respiratory control. Nocturnal awakenings and nocturnal use of rescue inhalers can be alternatives to waking up at night to relieve symptoms. Waking up at night is associated with poor asthma outcomes. Asthma control can be specifically determined through rescue use patterns (day and night) and asthma control tests.

[0072] As described above, the application may include an interface for self-reporting by the patient. Such data may include self-reported ACT data, self-reported quality of life, and self-reported exacerbations such as hospitalizations, OCS prescriptions, or medical provider appointments. Other sensor data may be collected by the system 100 that may be included in the analysis of responsiveness to a particular biologic. These may include passive activities, sleep data, home spirometry measurements, and responses to contaminants and irritants. Thus, nocturnal awakenings may be characterized by nocturnal inhaler use or a sleep tracking sensor. For example, the system may be linked to sleep data from a wearable sensor such as a FitBit, or a phone application such as an application available from Sleep Score Labs. Another data source may include a data connection to a smart syringe. Such smart syringes are known in the art and may be connected to the current system to confirm the use of the biologic, the date and time of use, the amount of drug, the batch of drug, etc.

[0073] Figure 6A shows an exemplary screen image of a patient population outcome graph 600 that summarizes data collected for a given patient population. The graph 600 and the collected data may be used to determine the suitability of a particular patient for biologic treatment, i.e., to examine population-level characteristics, and / or to make clinical decisions related to biologic treatment (as in Figure 6B), and / or to analyze the outcomes of a patient population that has received or is receiving biologic treatment, by classifying the population into different compliance and rescue use classes.

[0074] In one example, patients 18 years of age and older who self-reported asthma were enrolled in a 18-month digital health program. The program included an electronic medication monitor (EMM) that objectively and passively monitored inhaler use by the patients. The patients had both a controller and a rescue inhaler to treat their asthma. Usage data generated by the inhaler was sent to a dedicated smartphone application associated with each patient. In this example, patients who used the EMM for more than 90 days were grouped according to controller medication adherence and rescue use. Figure 6B is Table 650 of adherence associated with the rescue puff of the patient population. The adherence groups included quartiles of adherence of 0 - 24, 25 - 49, 50 - 74, and 75 - 100%. The groups of rescue use included patients who applied 1 - 3 puffs, 4 - 14 puffs, 15 - 28 puffs, and more than 28 puffs per week. Multivariable logistic regression identified whether age, gender, Asthma Control Test (ACT) score (5 - 15, 16 - 19, 20 and above), daily application start, and census tract level demographics were associated with the adherence and rescue use groups. The confidence level was α = 0.05.

[0075] As shown in Table 650, the percentages of study patients with 75 - 100% adherence, more than 28 rescue puffs per week, and both (n = 1263, mean age: 39 years, 79% female) were 18%, 6%, and 1.5%, respectively. Models identified as older, having an ACT score above 20, and more application starts were associated with having 75 - 100% adherence, while models with an ACT score of 5 - 15 and more application starts were associated with applying more than 28 rescue puffs per week.

[0076] Continuous monitoring in the system of FIG. 1 can be used to enable a patient to determine the selection of biologic agents for treating various respiratory diseases other than asthma, such as COPD, cystic fibrosis, and bronchiectasis. However, it should be understood and recognized that the above principles are not limited to such uses.

[0077] FIG. 7 is a flowchart 700 of a data collection and analysis routine for determining patients for enhanced treatment, such as biologic agents, according to certain aspects of the present disclosure. The flowchart of FIG. 7 depicts exemplary machine-readable instructions for a process of collecting data and selecting patients for enhanced treatment. In this example, the machine-readable instructions include an algorithm for execution by (a) a processor, (b) a control unit, and / or (c) one or more other suitable processing devices. The algorithm can be embodied in software stored in a tangible medium or a computer program product, such as a flash memory, a CD-ROM, a floppy (R) disk, a hard drive, a digital video (versatile) disk (DVD), or other memory devices having a non-transitory computer-readable storage medium. However, those skilled in the art will readily recognize that all or part of the algorithm can instead be executed by a device other than a processor and / or can be embodied in firmware or dedicated hardware in well-known ways (e.g., may be implemented by an application specific integrated circuit [ASIC], a programmable logic device [PLD], a field programmable logic device [FPLD], a field programmable gate array [FPGA], discrete logic, etc.). For example, any or all of the components of the interface can be implemented by software, hardware, and / or firmware. Also, some or all of the machine-readable instructions represented by the flowchart may be implemented manually. Further, although the exemplary algorithm is described with reference to the flowchart shown in FIG. 7, those skilled in the art will readily recognize that many other methods for implementing the exemplary machine-readable instructions may instead be used. For example, the order of execution of the blocks may be changed and / or some of the blocks described may be altered, deleted, or combined.

[0078] The routine first collects usage data for controllers and rescue in a general population of patients using respiratory medications (710). The usage data is collected over a period such as 90 days. The routine identifies patients who have sufficient data related to rescue and controller usage (712). The routine then examines the patients with sufficient data. The routine analyzes the usage data and determines patients who exceed a first threshold over a set period of compliance (714). In this example, the first threshold is patients with a compliance rate exceeding 75%.

[0079] The routine then analyzes patients with compliance exceeding the first threshold to determine patients with high rescue usage (716). In this example, the definition of high rescue usage is rescue usage exceeding a second threshold such as exceeding 28 puffs per week. The routine then stores the patients with high rescue usage (718). Any relevant medical data is retrieved for association with the patients (720). Next, the routine provides notice that the last group of patients is eligible for enhanced treatment such as a biologic (722).

[0080] As used in this application, terms such as "component", "module", "system", etc. generally refer to computer-related entities, either hardware (e.g., circuits), combinations of hardware and software, software, or entities having one or more specific functions of an operable machine. For example, a component can be, but is not limited to, a process running on a processor (e.g., a digital signal processor), a processor, an object, an executable file, an execution thread, a program, and / or a computer. As an example, both an application running on a control unit and the control unit can be components. One or more components may reside within an execution process and / or thread, and a component can be localized on one computer and / or distributed across two or more computers. Further, a "device" can exist in the form of specially designed hardware; generalized hardware specialized by the execution of software enabling specific functions on the hardware; software stored on a computer-readable medium; or a combination thereof.

[0081] The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to limit the invention. As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Further, as long as the terms "including", "includes", "having", "has", "with", or variations thereof are used in either the detailed description and / or the claims, such terms are intended to be inclusive in the same manner as the term "comprising".

[0082] Unless otherwise defined, all terms (including technical and scientific terms) used in this specification shall have the same meaning as commonly understood by one of ordinary skill in the art. Further, terms as defined in commonly used dictionaries shall be interpreted to have a meaning that coincides with the meaning in the context of the relevant art and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this specification.

[0083] Although various embodiments of the present invention have been described above, it should be understood that these are presented by way of example and not of limitation. The present invention has been illustrated and described with respect to one or more implementations, but equivalent changes and modifications will occur to, or be known to, those of ordinary skill in the art upon reading and understanding this specification and the accompanying drawings. Also, although a particular feature of the present invention may be disclosed with respect to only one of several implementations, such a feature may be combined with one or more other features of one or more other implementations as may be desired and advantageous for a given or particular application. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described embodiments. Rather, the scope of the present invention should be defined in accordance with the following claims and their equivalents.

Claims

**Claim 1** A system for determining the suitability of intensive treatment for a respiratory disease, comprising: a communication interface for collecting usage data of a respiratory drug device and delivering a controller or rescue respiratory drug to a patient; a storage device for storing the collected usage data; based on the collected usage data, determining whether the patient exceeds a first threshold level of compliance in the use of the respiratory drug device; based on the collected usage data, determining whether the patient uses a rescue respiratory drug exceeding a second threshold level; and a data analysis module operable to provide a notification of a recommendation for the intensive treatment when the patient exceeds the first threshold and the second threshold. **Claim 2** The system according to claim 1, wherein the respiratory disease is asthma. **Claim 3** The system according to any one of claims 1-2, wherein the intensive treatment is a prescription of a biologically based treatment or therapy. **Claim 4** The system according to any one of claims 1-3, wherein the first threshold is a compliance rate of at least about 65% compliance. **Claim 5** The system according to any one of claims 1-4, wherein the second threshold exceeds at least about 15 uses of a rescue drug over a one-week period. **Claim 6** The system according to any one of claims 1-5, further comprising a mobile computing device communicating with the storage device and the communication interface. **Claim 7** The system according to claim 6, wherein the mobile computing device includes an application for assisting the patient to whom the intensive treatment is applied. **Claim 8** The system according to any one of claims 1-7, wherein the notification is provided electronically to one of the patient, a caregiver, or a healthcare provider. **Claim 9** The system according to any one of claims 6-8, further comprising an intensive treatment module engine communicating with the mobile computing device, the intensive treatment module being operable to track the use of the intensive treatment by the patient. **Claim 10** The system according to claim 9, wherein the intensive treatment module is operable to instruct the patient to receive additional intensive treatment. **Claim 11** The system according to any one of claims 6 to 10, wherein the enhanced treatment is a prescription of an injectable biologic agent, and the application includes an interface for instructing the patient about at least one injection technique.

12. The system according to claim 11, wherein the interface includes an interface for recording an area of injection of the biologic agent.

13. The system according to any one of claims 1 to 12, further comprising a health monitor for monitoring the patient, wherein the data analysis module is operable to further collect data from the health monitor to determine the patient's response to the enhanced treatment.

14. A method for determining whether a patient should receive enhanced treatment for a respiratory disease, comprising: collecting usage data of a respiratory drug device and delivering a controller or rescue respiratory drug to the patient via a communication interface; transmitting the usage data to a storage device; storing the usage data in the storage device accessible to a data analysis module; determining, based on the collected usage data, whether the patient exceeds a first threshold level of compliance in the use of the respiratory drug device; determining, based on the collected usage data, whether the patient uses a rescue respiratory drug in excess of a second threshold level; and providing a notification of a recommendation for the enhanced treatment when the patient exceeds the first and second thresholds.

15. The method according to claim 14, wherein the respiratory disease is asthma.

16. The method according to any one of claims 14 to 15, wherein the enhanced treatment is a prescription of a biology-based treatment or therapy.

17. The method according to any one of claims 14 to 16, wherein the first threshold is a compliance rate of at least about 65% compliance.

18. The method according to any one of claims 14 to 17, wherein the second threshold is at least about 15 uses of a rescue drug over a week.

19. The method according to any one of claims 14 to 18, further comprising establishing communication to a mobile computing device using the storage device and the communication interface.

20. The method according to claim 19, wherein the mobile computing device includes an application for assisting the patient to whom the enhanced treatment is applied.

21. The method according to any one of claims 14 to 20, wherein the notification is provided electronically to one of the patient, the caregiver, or the healthcare provider.

22. The method according to any one of claims 19 to 21, further comprising tracking the use of the enhanced treatment by the patient.

23. The method according to claim 22, wherein the enhanced treatment module is operable to direct additional enhanced treatment to the patient.

24. The method according to any one of claims 19 to 23, wherein the enhanced treatment is a prescription of an injectable biologic, and the application includes an interface for instructing the patient about at least one injection technique.

25. The method according to claim 24, wherein the interface includes an interface for recording the area of injection of the biologic.

26. monitoring the patient via a health monitor to monitor the patient; and collecting data from the health monitor to determine the patient's response to the enhanced treatment. The method according to any one of claims 14 to 25, further comprising:

27. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 14 to 26.

28. The computer program product according to claim 27, wherein the computer program product is a non-transitory computer-readable medium.

Images