Preemptive asthma risk notification based on drug-device monitoring

Abstract

The asthma analysis system provides asthma risk notifications in advance of predicted rescue use events to help influence patient behavioral change and prevent those events from occurring. Information related to rescue medication events, changes in environmental conditions, and other circumstances is detected by sensors associated with the patient's medication device and collected from other sources, respectively, to provide the basis for determining the patient's risk score. This data is analyzed to determine the severity of the patient's risk for an asthma event and used to send notifications accordingly.

Description

[Technical field]

[0001] The present disclosure relates generally to methods of improving treatment for patients who use inhalers, and more specifically to determining a patient's risk of an asthma-related rescue event. [Background technology]

[0002] Asthma remains a significant and costly public health problem. Globally, the World Health Organization estimates that asthma may affect 300 million people, projecting this to increase to 400 million by 2025. In the United States, asthma affects 1 in 12 people, with prevalence rising, and is responsible for more than $56 billion in healthcare utilization costs annually.

[0003] Despite the development of new drugs, hospitalization and emergency room visit rates have not declined. Each year in the United States, the disease causes approximately 2 million emergency department visits, 500,000 hospitalizations, and 5,000 deaths. In addition, asthma is responsible for an estimated 15 million missed school days and 12 million missed work days. The total annual cost to U.S. health insurers and employers exceeds $18 billion.

[0004] Most of these exacerbations can be prevented with currently available treatments. However, only one in five people with asthma has the disease under control. Newly revised national guidelines call on doctors to monitor more closely whether treatment is controlling daily symptoms and improving quality of life. However, doctors have few tools available to assess how well their patients are doing day to day. More and more doctors are beginning to use periodic written questionnaires (such as the Asthma Control Test) to monitor their patients and determine their level of control. These measures require patients to accurately recall and report the frequency of symptoms, inhaler use, as well as activity levels and limitations over a period of time (usually 2–4 weeks). As a result, these questionnaires are subject to errors introduced by bias (recall), different interpretations of symptoms, and behavior (non-adherence) and only provide information at the time they are used.

[0005] More generally, pharmaceutical devices such as inhalers allow patients to manage respiratory symptoms such as restricted airflow. Many respiratory disease patients, such as those with asthma, chronic obstructive pulmonary disease (COPD), and cystic fibrosis, have symptoms that are related to environmental triggers and factors, such as air quality, weather, land use, etc. Patients who know which environmental triggers and factors affect their symptoms can allow them to better manage their symptoms and reduce the chance of needing emergency medical care. However, certain patients or groups of patients may be sensitive to multiple triggers and factors. Knowing which of dozens, hundreds, or more triggers and factors a patient is sensitive to and monitoring those triggers and factors for use in managing symptoms is a complex task and is not currently feasible for many patients and providers. Summary of the Invention

[0006] The asthma analysis system is an integrated platform for treating, monitoring, and managing rescue events due to asthma. The asthma analysis system tracks asthma rescue medication events by receiving event notifications from sensors attached to medication devices (e.g., inhalers) used by patients who have approved the asthma analysis system to assist in managing their asthma. The sensors, if attached to or incorporated into a metered-dose inhaler or other medication device, record the geographic location, time, and date of the rescue use event and communicate that information to the asthma analysis system. The asthma analysis system analyzes the received events (both current and previously received events) in real-time or near real-time and delivers risk assessment and disease guidance and management information in the form of notifications to patients and healthcare providers.

[0007] The patient-specific risk score is determined using a combination of parameters including the patient's medical history, the patient's daily current condition, and environmental conditions related to atmospheric and weather conditions. The relationship between these parameters and the risk assessment generated for the patient is embodied in a machine learning model. The model, and more generally the system, can receive input values ​​for the parameters and predict the number of drug puffs the patient will take each day. The system can further determine a patient-specific risk score based on the prediction, classify the risk score, and provide a risk assessment along with accurate and medically relevant treatment options to mitigate the risk.

[0008] By incorporating information regarding the timing, frequency, and location of medication use, along with other contextually relevant parameter information, the asthma analysis system can help prevent future asthma rescue use events from occurring by suggesting immediately applicable behavioral or environmental changes prior to those predicted events, facilitating better management of asthma therapy by patients and their healthcare providers and improving recognition of specific locations that trigger rescue events so that patients can avoid or adapt to these locations in the future. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates an asthma analysis system for monitoring accurate real-time medication device usage, performing analytics on that data, and providing asthma rescue event risk notifications, according to one embodiment. [Diagram 2] FIG. 2 is a high-level block diagram illustrating an example of a computing device used as either a client device, an application server, and / or a database server, according to one embodiment. [Figure 3A] FIG. 3A illustrates a dashboard of a client application that allows a user to interact with the asthma analysis system, according to one embodiment. [Figure 3B] FIG. 3B illustrates an example card displayed within a dashboard of a client application, according to one embodiment. [Figure 4] FIG. 4 is an interaction diagram for providing asthma risk-based notification based on medication device monitoring, according to one embodiment. [Diagram 5] FIG. 5 is a flow chart for detecting a rescue medication event by an asthma analysis system, according to one embodiment. [Figure 6] FIG. 6 is a block diagram illustrating modules within the asthma risk module, according to one embodiment. [Figure 7] FIG. 7 illustrates a process for determining a patient's asthma risk using components of the data analysis module 131, according to one embodiment. [Figure 8] FIG. 8 illustrates a method for training a model using a training dataset, according to one embodiment. [Figure 9A] FIG. 9A illustrates a visualization of the output generated by a nonlinear model, according to one embodiment. [Figure 9B] FIG. 9B illustrates a visualization of the output generated by the nonlinear model, according to one embodiment. [Figure 10A] FIG. 10A is a diagram characterizing and analyzing data used to test an asthma risk analysis, according to one embodiment. [Figure 10B] FIG. 10B is a diagram characterizing and analyzing data used to test an asthma risk analysis, according to one embodiment.

[0010] These figures depict various embodiments of the present invention for purposes of illustration only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods described herein may be employed without departing from the principles described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] I. System Environment FIG. 1 illustrates an asthma analysis system 100 for monitoring accurate real-time medication device usage, performing analytics on that data, and providing asthma rescue event risk notifications, according to one embodiment.

[0012] The asthma 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. Although Figure 1 shows only a single instance of most of the components of the asthma analysis system 100, in practice there may be more than one of each component, and additional or fewer components may be used.

[0013] IA Client Devices and Applications The client devices 110 interact with the asthma analysis system 100 via the network 150 at the request of their users. For purposes of explanation and clarity, it is helpful to identify at least two different types of users. A patient 111 is a user who suffers from asthma and utilizes the asthma analysis system 100, at least in part, to obtain personalized asthma rescue event risk notifications provided by the server 130 and asthma management notifications created by a healthcare provider 112. Such notifications may be provided in exchange for the user's permission to allow the asthma analysis system 100 to monitor the use of the patient's 111 medication device 160. As described below, medication events are detected by sensors 120 associated with the medication device 160 and the user's client device 100, which may then be reported to the application server 130, in turn initiating a process to generate a risk notification that is provided to the user via the client device 110.

[0014] Another type of user is a healthcare provider 112 who, again with the explicit permission of the patient 111, also receives 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 are also contemplated, such as a parent / guardian of a patient 111 who may want to receive notifications if their client device 110 is different from that of their child.

[0015] The client device 110 is a computer system. An exemplary physical implementation is described more fully below with respect to FIG. 2. The client device 110 is configured to wirelessly communicate with the asthma analysis system 100 over a network 150. Upon accessing the network 150, the client device 110 transmits to the application server 130 the user's geographic location and time of the rescue medication event, as well as information describing the event received from an associated medication device sensor 120 (referred to throughout as "sensor 120").

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

[0017] In addition to communicating with the application server 130, the client devices 110 wirelessly connected to the application server 130 may also exchange information with other connected client devices 110. For example, via the client software application 115, a healthcare provider 112 may receive a risk deterioration notification describing a recent rescue event for the patient 111 and then, in response, send recommendations to the patient 111 for post-asthma rescue event treatment. Similarly, via the application 115, the patients 111 may communicate with their healthcare providers 112 and other patients 111.

[0018] The application 115 provides a user interface (referred to herein as a "dashboard") that is displayed on the screen of the client device 110 and allows the user to enter commands to control the operation of the application 115. The dashboard is a mechanism by which the healthcare provider 112 and the patient 111 access the COPD analysis system 100. For example, the dashboard allows the patient 111 and the provider 112 to interact with each other, receive risk notifications for asthma rescue events, exchange messages regarding treatment, provide and receive additional event and non-event data, and the like. The application 115 may be coded as a web page, a series of web pages, or content otherwise coded to render within an Internet browser. The application 115 may also be coded as a proprietary application configured to run on the native operating system of the client device 110. The dashboard is described more fully below in conjunction with FIG. 3.

[0019] In addition to providing the dashboard, application 115 may also perform some data processing on the asthma rescue event data locally using resources of client device 110 before transmitting the processed data over network 150. The event data transmitted over network 110 is received by application server 130 where it is analyzed and processed for storage and retrieval in conjunction with database server 140. Application server 130 may direct retrieval and storage requests to database system 130 when requested by client application 115.

[0020] The client device 110 communicates with the sensor 120 using a network adapter and either a wired or wireless communication protocol, one example of which is the Bluetooth Low Energy (BTLE) protocol. BTLE is a short-range, low-power protocol standard that transmits data wirelessly over radio links in a short-range wireless network. After the sensor 120 and the client device 110 are paired with each other using a BTLE passkey, the sensor 120 automatically synchronizes and communicates information about the use of the drug device with the client device 110. If the sensor 120 is not paired with the client device 110 prior to a rescue medication event, the information is stored locally by the sensor 120 until such pairing occurs. Upon pairing, the sensor 120 communicates the stored event record to the client device 110. In other implementations, other types of wireless connections are used (e.g., infrared or 802.11).

[0021] Although the client device 110 and the medication device 160 are described above as being separate physical devices (such as a smartphone and an inhaler, respectively), the medication device 160 may include aspects of the client device 110 as well as the sensor 120 integrated into a single housing with the device 160. For example, the medication device 160 may include an audiovisual interface including a display or other lighting elements, as well as a speaker for presenting visual and audible information. In such an implementation, the medication device 160 itself may directly present the contents of notifications provided by the server 130 instead of or in addition to presenting them via the client device 110.

[0022] IB Drug Devices and Sensors The drug device 160 is a medical device used to deliver medication to the lungs of a user experiencing suppressed respiratory airflow. Drug devices (such as inhalers) are typically portable and small enough to be carried by hand for easy access when treating respiratory attacks. In one embodiment, the medication is delivered in aerosol form via a drug device 160, such as a metered dose inhaler. A metered dose inhaler includes a pressurized propellant canister of aerosol medication, a metering valve for delivering a regulated dose of medication, and a plastic holder that holds the pressurized canister and forms a mouthpiece for delivering the medication. In another embodiment, the medication is delivered in dry powder form via a drug device 160, such as a dry powder inhaler. A dry powder inhaler may include a Cartesian egg-shaped body that houses a mechanism of wheels and gears that allows a user to index through a piece of dry powder medication. 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, budesonide, and fluticasone, as well as combinations of these drugs with long-acting bronchodilators such as salmeterol or formoterol. Examples of rescue drugs dispensed by the rescue drug device 160 include albuterol, salbutamol, levalbuterol, metaproterenol, and terbutaline.

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

[0024] In general, the sensor 120 is a physical device that monitors the use of the drug dispenser 160. The sensor 120 may be removably attachable to the drug dispenser without interfering with the operation of the drug dispenser, or the sensor 120 is an integrated component that is an inherent part of the drug dispenser 160 made available by its manufacturer.

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

[0026] The sensor 120 may also be configured to communicate more directly with the application server 130. For example, if the network adapter of the sensor 120 is configured to communicate over a wireless standard such as 802.11 or LTE, the adapter may exchange data with a wireless access point, such as a wireless router, which may then communicate with the application server 130 without necessarily involving the client device 110 in every exchange of data. These two communication methods are not mutually exclusive, and the sensor 120 may be configured to communicate with both the client device 110 and the application server 130 using redundant transmissions to ensure that event data arrives at the application server 130, or to provide information directly to the client device 110 while the application server 130 determines what notification to provide in response to an event.

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

[0028] To achieve this goal, there are several different ways to construct the sensor 120, and in part, the construction will depend on the construction of the medication device itself 160. Generally, all sensors 120 include an on-board processor, persistent memory, and the network adapter described above, which together function to record, store, and report medication event information to the client device 110 and / or server 130. The sensor 120 may also include a clock to record the date and time of an event.

[0029] With regard to the structure of a particular sensor 120, conventional inhalers, such as mechanical dose counters, were not designed with the sensor 120 in mind, and thus the sensor 120 may be constructed accordingly. Some implementations of this method include mechanical, electrical, or optical sensors to detect device 160 movement, priming of the device, activation of the device, inhalation by a user, and the like. In contrast, modern inhalers, such as deflectable membrane dose counters, include electrical circuitry that may report event information as electrical data signals that the sensor 120 is designed to receive and interpret. For example, the drug device 160 itself may report movement, priming, and activation to the sensor 120. In one embodiment, the sensor detects movement of the drug device, such as the opening of a drug cover, indicating that the drug is being dispensed. In an alternative embodiment, the sensor may detect movement of the canister to a position where the drug is dispensed. After detecting such movement, indicating that the drug device has been activated, the sensor may report that the drug device has dispensed the drug and the time at which the drug has been dispensed.

[0030] Details regarding the hardware and software components of the sensor 120 and the medication device 160 and the interaction between them for recording rescue medication events are described in U.S. patent application Ser. No. 12 / 348,424, filed Jan. 1, 2009, and International Application No. PCT / US2014 / 039014, filed May 21, 2014, both of which are incorporated by reference in their entireties into this specification.

[0031] IC Application Server The application server 130 is a computer or a network of computers. Although a simplified example is shown in FIG. 2, typically the application server 130 is a server class system that uses powerful processors, large memory, and faster network components compared to a typical computing system used as, for example, a client device 110. The server typically has large amounts of secondary storage, for example, using RAID (Redundant Array of Independent Disks) arrays and / or by establishing relationships with independent content delivery networks (CDNs) that undertake to store, exchange, and transmit data, such as the asthma notifications discussed above. Additionally, the computing system includes an operating system, for example, a UNIX operating system, a LINUX operating system, or a WINDOWS operating system. The operating system manages the hardware and software resources of the application server 130 and also provides various services, such as process management, data input and output, and management of peripheral devices. The operating system provides various functions for managing files stored on the device, such as creating new files, moving or copying files, transferring files to remote systems, and the like.

[0032] The application server 130 includes a software architecture to support access to and use of the asthma analysis system 100 by many different client devices 110 via the network 150, and thus at a high level may 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 medication devices 160, including both rescue medication and controller medication events, collaborate on asthma treatment plans, view and obtain information related to their condition and geographic location, as well as utilize a variety of other functions.

[0033] In general, application server 130 is designed to process a wide variety of data. Application server 130 contains logic routines that perform a variety of functions, including checking the validity of incoming data, parsing and formatting the data if necessary, passing the processed data to database server 140 for storage, and ensuring that database server 140 has been updated.

[0034] The application server 130 stores and manages data at least partially on a patient-by-patient basis. To this end, the application server 130 creates a patient profile for each user. A patient profile is a set of data that characterizes a patient 111 of the asthma analysis system 100. The patient profile may include identifying information about the patient, such as age, gender, current rescue medication, current controller medication, notification settings, controller medication adherence plan, patient-related medical history, and a list of non-patient users authorized to access the patient profile. The profile may further specify a device identifier, such as a unique media access control (MAC) address, that identifies one or more client devices 110 or sensors 120 authorized to submit data (such as controller and rescue medication events) for the patient.

[0035] The profile may specify which different types of notifications are provided to the patient 111 and their personal healthcare provider 112, as well as the frequency with which the notifications are provided. For example, the patient 111 may allow the healthcare provider 112 to receive notifications indicating rescue events. The patient 111 may also allow their healthcare provider 112 to be given access to their patient profile and rescue event history. If the healthcare provider 112 is provided access to the patient's 111 patient profile, the healthcare provider may specify a controller adherence or rescue medication regimen. The medication regimen may include the number of prescribed doses per day for controller medication.

[0036] The application server 130 also creates profiles of the healthcare providers 112. The healthcare provider profiles may include identifying information about the healthcare providers 112, such as office location, qualifications and certifications. The healthcare provider profiles also include information about their patient population. The provider profiles may include access to all of the profiles of that provider's patients, as well as data derived from their profiles, such as aggregated demographic information, rescue and controller dispensing event patterns. This data may be further broken down according to any type of data stored in the patient profile, such as by geographic area (e.g., neighborhood, city), by time period (e.g., weekly, monthly, yearly), etc.

[0037] The application server 130 receives rescue medication event information from the client device 110 or the sensor 120, which triggers various routines on the application server 130. In an exemplary implementation described below, the data analysis module 131 executes routines that access the asthma event data and other data, including the patient's profile, analyze the data, and output the results of the analysis to both the patient 111 and the provider 112. This process is generally referred to as asthma risk analysis. The asthma risk analysis may be performed at any time in response to a rescue event, in response to relevant changes in the patient's environment, and in response to any of several trigger conditions described further below.

[0038] Other analyses are possible. For example, risk analysis may be performed on rescue and controller drug usage for multiple patients to identify based on spatial / temporal clusters (or occurrences) of drug usage based on individual, geographic, clinical, epidemiological, demographic, or historically significant permutations from baseline or predicted or expected values ​​over space or time. Other types of analyses may include daily / weekly adherence trends, changes in adherence over time, comparisons to other relevant populations (e.g., all patients, patients with a particular rescue or controller drug or combinations thereof, identification of triggers (spatial, temporal, environmental), trends in rescue usage over time, and comparisons of rescue usage with other relevant populations.

[0039] In response to the analysis performed, the application server 130 prepares and delivers a push notification to be sent to the patient 111, the authorized healthcare provider 112, and / or other users provided with access to the patient profile. The notification may provide details regarding the timing, location, and affected patient 111 involved in the medication rescue event. The notification may further include a distress or emergency signal requesting emergency assistance that is delivered to the emergency assistance 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 sent and the content they may include are discussed further below.

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

[0041] The notification may be provided to the client application 115 over the network 150 in a data format specifically designed for use by the client application, or may additionally or alternatively be provided as a Short Message Service (SMS) message, email, telephone call, or other data format communicated using other communications media. ID Database Server The database server 140 stores patient and provider data related data such as profiles, medication events, and patient medical history (e.g., electronic medical records). Patient and provider data is encrypted for security and is at least password protected or otherwise protected to meet all Health Insurance Portability and Accountability Act (HIPAA) requirements. Analyses (e.g., asthma risk analysis) incorporating data from multiple patients (e.g., aggregated rescue medication event data) and provided to users are anonymized and have personally identifying information removed to protect patient privacy.

[0042] The database server 140 also stores non-patient data used in the asthma risk analysis. This data includes area data for many geographic regions, such as public spaces in residential or commercial zones where patients are physically located and may be exposed to pollutants. This data may include or be processed to capture, among other things, the patient's proximity to green spaces (areas with a concentration of trees and plants). One example of area data includes georeferenced weather data, such as temperature, wind patterns, humidity, and air quality index. Another example is georeferenced pollution data, including particle counts of various pollutants at a point in time or measured empirically. Area data includes information about current weather conditions at the time and location of the rescue event, such as temperature, humidity, and air quality index. All of the above items of data may change over time, and thus the data itself may be indexed by time, e.g., individual data points may be available for each time of day (including minutes or hours) or for longer periods such as days, weeks, months, or seasons. Although database server 140 is shown in FIG. 1 as being a separate entity from application server 130, database server 140 may instead be a hardware component that is part of another server, such as server 130, such that database server 140 is implemented as one or more persistent storage devices with a software application layer for interfacing with data stored in databases that are part of the other server 130.

[0043] The database server 140 stores data according to a defined database schema. Typically, data storage schemas among various data sources vary significantly due to differences in the implementation of the underlying database structure, even when storing the same type of data, such as cloud application event logs or log metrics. The database server 140 may also store different types of data, such as structured, unstructured, or semi-structured data. Data in the database server 140 may be associated with users, groups of users, and / or entities. The database server 140 manages the 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.) that specifies instructions for reading information from or writing information to the database server 140.

[0044] 6A-6D below, the contents of the databases described with respect to those figures may be stored in databases that are physically proximate to application server 130 and separate from database server 140, as shown. Alternatively, those databases may be part of database server 140, as opposed to the description of Figures 6A-6D which shows them as being within data analysis module 131. This and other variations are within the scope of this description.

[0045] IE Network Network 150 represents various wired and wireless communication paths between client 110 devices, sensors 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), and the like. Similarly, networking protocols used in network 150 may include Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and the like. Data exchanged over network 150 may be represented using technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like. Additionally, all or some of the links may be encrypted using conventional encryption technologies such as Secure Sockets Layer (SSL), Secure HTTP (HTTPS), and / or Virtual Private Networks (VPNs). In alternative embodiments, the entities may use custom and / or proprietary data communications techniques instead of or in addition to the techniques described above.

[0046] II. Exemplary Computing Devices 2 is a high-level block diagram illustrating the physical components of an exemplary computer 200 that may be used as part of the client device 110, application server 130, and / or database server 140 from FIG. 1, according to one embodiment. Shown is a chipset 210 coupled to at least one processor 205. Coupled to the chipset 210 are volatile memory 215, a network adapter 220, input / output (I / O) devices 225, a storage device 230 representing non-volatile memory, and a display 235. In one embodiment, the functionality of the chipset 210 is 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 device.

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

[0048] As is known in the art, computer 200 may have different and / or other components than those shown in FIG. 2. Additionally, computer 200 may lack certain illustrated components. In one embodiment, computer 200 functioning as server 140 may lack dedicated I / O devices 225 and / or display 218. Additionally, storage device 230 may be local and / or remote from computer 200 (such as embodied in a storage area network (SAN)).

[0049] In general, the exact physical components used in the client device 110 will differ in size, power requirements, and performance from those used in the application server 130 and the database server 140. For example, the client device 110 is often a home computer, tablet computer, laptop computer, or smartphone, and includes relatively small storage and processing capabilities, but includes an input device and a display. These components are suitable for user input of data, as well as receiving, displaying, and interacting with notifications provided by the application server 130. In contrast, the application server 130 may include many physically separate, locally networked computers, each having a significant amount of processing power to perform the asthma risk analysis introduced above. In one embodiment, the processing power of the application server 130 is provided by a service such as Amazon Web Services. Also in contrast, the database server 140 may include many physically separate computers, each having a significant amount of persistent storage capacity to store data related to the application server.

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

[0051] III. Dashboard Dashboards, such as the dashboard 300 shown in FIG. 3A, allow users to interact with the asthma analysis system 100. The dashboard 300 provides a means for transferring information on a user-to-user (e.g., patient 111 to provider 112) or user-to-system / system-to-user basis. The dashboard 300 is accessed via a client application 115 on a client device 110 and provides a mechanism for both patients and healthcare providers to monitor medication rescue events, exchange personalized patient medical information, and receive notifications, such as asthma rescue event risk notifications. Patients may communicate with other healthcare providers and other patients via the dashboard 300, for example, to discuss and share information about asthma, medication use, or asthma management. The ability to share asthma medical information may provide patients or healthcare providers experiencing similar issues a way to share individual perspectives.

[0052] The dashboard 300 also allows authorized healthcare providers 112 to access a list of patients to view, annotate, update, interact with, and export information about asthma patient and community data and statistics by various demographic or geographic segments. Using the dashboard 300, healthcare providers can monitor patients individually or collectively and receive and provide feedback on how their associated patient populations are responding to asthma management guidance. Healthcare providers with access to individual patients or multiple patients can set notification thresholds, configure notification parameters, and receive notifications when a patient's event history matches certain conditions (such as a rescue event). Additionally, the dashboard 300 can receive and display periodic reports of event patterns for specific demographics generated by the asthma analysis system 100.

[0053] The dashboard 300 presents a variety of information, including tabular data, graphical visualizations, and analyses, to the user via display "cards" 310. The display cards 310 are adapted to fit the small displays typical of a portable client device 110, such as a mobile phone or tablet, and contain "bite-sized" information that mimics the simple organizational style found on baseball cards. The dashboard 300 may also include a system menu 305 that allows the user to navigate through different categories of medical information.

[0054] Notifications provided by the application server 130 are associated with display cards 310. In general, notifications include not only the information to be presented to the user via the application 115, but also parameters to specify which display card 310 is used to display the content of the notification. Information pushed / pulled from the application server 130 may be associated with one or more cards. For example, a notification may be pushed to a patient based on the results of an asthma risk analysis. The dashboard 300 processes the notification and determines which card to use to present the information in the notification. Continuing the example, a recipient of the notification may request to pull data from the application server 130. The application server 130 provides the requested data in another notification, and the dashboard 300 then determines which display card 310 to display the requested information.

[0055] To interact with the presented information, some display cards 310a include an input response 315 area. For example, in the display card 310b shown in FIG. 3B, the patient can scroll up or down the input response 315 area to select a controller medication used to manage their asthma or select "next" to move to an additional display card 310.

[0056] The dashboard 300 may provide a variety of different display cards 310 that may be organized into categories. Information card types include cards that display data. Information cards may display, for example, medication rescue events, statistics, and maps that include both patient and community data. Information cards are further subcategorized into event, trend, education, and alert display cards.

[0057] The event card includes data related to rescue medication events, such as a list of past medication rescue events for a particular patient, or patient rescue event data overlaid on a geographic map for a particular provider.

[0058] 3B illustrates an exemplary display card 310a transmitted by notification module 645 (described below) that is transmitted based on a risk score determination by data analysis module 131. Display card 310a highlights patient information derived from inputs used to determine the risk score, such as the patient's current geographic location as specified by device 110, and environmental information. Display card 310a also includes a risk classification based on the risk score, in this case "fair," which may represent a moderate risk classification.

[0059] Another event card may display an exemplary medication usage report, including a map of the location of the rescue use event, the environmental conditions at that location, and an input response area 315 for the recipient to add a rescue use event trigger. Another event trend card may display rescue device usage for the past week, including total uses and uses for each day for that period.

[0060] Trend cards contain statistical information presented using graphs or charts designed for clear understanding by the recipient. Examples of trend cards include plots of asthma rescue events over various time periods, time of day trends, day of week trends, and trigger trends.

[0061] Education cards contain information to educate the recipient. Education cards provide common disease information and tips for patients to reduce their risk of a rescue event. Some education cards may require an input response 315 to allow the recipient to specify whether the information provided is relevant or interesting for use in providing future cards.

[0062] Alert cards inform users of important information, including informing recipients that they are at risk for an event and / or that no data has been received from the device in a recent period. Other alerts may include alerts that client device settings are preventing data synchronization (e.g., Bluetooth is turned off) or that the patient's asthma risk score has changed.

[0063] Survey card types solicit user responses by presenting the user with yes / no, multiple choice, or open-ended questions. For example, a healthcare provider or the asthma analysis system 100 may send a survey card along with an asthma-related questionnaire to the patient 111 to determine the level of disease control for a particular patient. Additionally, the survey card may request the type of controller medication the patient 111 uses to treat asthma symptoms. In general, the survey card provides the application server 130 with data that may be missing from the patient's medical history or patient profile (as introduced above) and / or provides updates to potentially outdated information. One or more survey cards may be used to complete the patient registration process and create a patient profile for storage in the database server 140. For example, when the patient 111 initially registers with the asthma analysis system 100, a push notification is triggered by the application server 130 prompting the patient 111 to create a patient profile.

[0064] Examples of survey cards may include survey questions asking whether the patient has visited an emergency room as a result of an asthma rescue event, information about the patient's controller medication, the number of times the patient has used rescue medication to control an event, and what the daily schedule of their controller medication is. Survey cards may ask about the patient's asthma triggers, such as whether pollen is a trigger. Some survey cards may ask the patient to rate the patient's general quality of life on a 5-point Likert scale, rate the patient's quality of sleep, rate the patient's ability to perform activities over the past 7 days, etc. Other survey cards ask whether the patient is feeling better or worse than yesterday, whether the patient has had to go to the emergency room or hospital in the past 12 months because of a rescue event, etc.

[0065] In some cases, patient behavior or sensor-reported event information that conflicts with existing patient information may trigger the sending of a survey card to resolve ambiguity regarding the patient's status. For example, if a patient is experiencing a higher than expected number of asthma events, the survey card may request information regarding the type of medication the patient currently has listed on their medication device 160 to ensure the correct medication is being used. Another example includes if reported information regarding controller medication use indicates that the patient is only using the controller medication once a day, but their adherence plan indicates that they are supposed to take the controller medication twice a day, the system 100 may send a notification asking if the patient needs to change their adherence plan.

[0066] In some cases, patient behavior or sensor-reported event information that conflicts with existing patient information may trigger the sending of a survey card to resolve ambiguity regarding the patient's status. For example, if a patient is experiencing a higher than expected number of asthma events, the survey card may request information regarding the type of medication the patient currently has listed on their medication device 160 to ensure the correct medication is being used. As another example, if reported information regarding controller medication use indicates that the patient is only using the controller medication once a day, but the adherence plan indicates that the controller medication is to be taken twice a day, the system 100 may send a notification asking whether the patient needs to change their adherence plan.

[0067] The navigation card represents actionable data or messages that, upon user interaction, may redirect the user to another screen or card that is part of the dashboard 300. For example, if a patient wishes to share information with a physician or request a specific medication regimen for a controller medication, the navigation card would be used to facilitate the sharing of information or enrollment in a controller adherence regimen. Additionally, the navigation card allows the user to update information regarding medication rescue events.

[0068] The adherence card is designed to encourage the patient to continue using the controller medication on schedule over various time periods. The adherence card may indicate a "streak" or continued execution of on-time controller dosing events. Additionally, the survey card may inquire about the patient's physical condition in response to recording a significant number of rescue events within a threshold period of each other. The controller dosing events may be represented as a graph showing when the patient 111 did and did not take controller dosing on time during various periods of the day as prescribed by the healthcare provider 112. The card may also detail a daily schedule of controller dosing, and an indicator to display whether the scheduled doses were taken. For example, a red "X" may indicate that a scheduled dose was not taken, while a green checkmark or another symbol may indicate that a scheduled dose was taken.

[0069] The setup card guides the recipient in associating the sensor with the client device 110. The setup card may guide the recipient in pairing the sensor to the client device 110 using Bluetooth and may prompt the recipient to begin the pairing process or prompt the user to select a sensor device to pair with, or may notify the user that the sensor is paired.

[0070] In some embodiments, the dashboard may present a user interface. The user interface may show a list of rescue events in response to a user's selection of the "View Timeline" input response area 315c. The list shows rescue use events over a period of time and includes details such as date, time, number of puffs, location, etc. The recipient may edit the rescue use event and / or add further details by selecting an edit dialogue response area. Some interfaces may present the user with an event summary of the rescue use event. The event summary may be presented to the user in response to the user selecting an edit dialogue response area of ​​the user interface. From the dashboard, the user may also view and edit a medication list describing details such as medication type (rescue, controller, etc.), medication schedule, and sensors.

[0071] IV. Event-driven Asthma Risk Notification 4 shows an interaction diagram for providing asthma risk notification based on medication device monitoring, according to one embodiment. As a first step, a patient interfaces with the dashboard 300 to initialize a patient profile 405. Once the patient has completed their patient profile, the client device 110 transmits the patient profile for use by the application server 130 and for storage by the database server 140. Once the patient's patient profile has been initialized 405, the application server 130 may begin receiving rescue medication events detected by the sensor 120 associated with the patient's medication device 160. The initialization and completion of the patient profile is performed only once, the first time the patient uses the medication device.

[0072] When the sensors detect a rescue use event 410, the client device 110 collects and transmits the rescue event data to the application server 130, where the event information is stored 415. Although only one such example is shown in Figure 4, this detection and storage process is typically performed with some frequency for many patients as rescue use events are detected, however, this frequency may differ from the frequency with which risk analysis is performed.

[0073] 5, the application server 130 generally receives rescue events whenever a patient uses their rescue medication dispenser 160 to alleviate asthma-related event symptoms. As an example of a process for capturing such events for a particular device 160 / sensor 120 combination, at the onset of an episode, the sensor 120 may detect whether the cover of the medication dispenser 160 is open 505. Once the medication dispenser cover is opened, the sensor 120 may detect an acceleration associated with priming the dispenser 160 510. For some types of medication dispensers, "priming" involves activating a mechanism that releases a dose of medication from a package. For other types of medication dispensers, "priming" involves rapid shaking of the medication canister.

[0074] After a priming action is detected, the sensor 120 is configured to store data associated with the rescue event in the active memory of the sensor 120 515. The rescue event data may include information describing the date and time associated with the rescue event, the status or condition of the drug device 160 (e.g., battery level), the number of doses of drug remaining (before or after the event), self-test results, and physiological data of the patient being treated with the drug device 160 measured by the sensor 120. When the sensor establishes a network connection with either the client device 110 or the network 150, the sensor transmits 525 the locally stored rescue event data to the client device 110 or the application server 130. If the event data was initially transmitted to the client device 110, the client device 110 then transmits 530 the rescue event data to the application server 130 when the client device 110 establishes a network connection with the network 150. Depending on the implementation, either the client device 110 or the sensor 120 adds the geographic location where the event occurred to the event data transmitted to the application server 130.

[0075] Returning now to FIG. 4, upon detecting 410 a rescue use event, event data is collected and stored 415. Upon receiving and storing 415 the rescue use event data, the application server 130 may request further information from the patient describing the rescue use event. To obtain the information, the application server 130 generates a push notification including the question to be asked that is sent to the patient's client device 110. The client device 110 may present the push notification as a survey type card 310. The patient may respond to the request by providing input 315 in response to the survey card 310. Alternatively, the patient 111 may choose not to respond to the request. This is acceptable and gaps in information may be obtained through a later push notification or when the provider 112 enters after a meeting with the patient 111. In one embodiment, failure to receive additional requested data in response to the request does not preserve the remainder of the analysis described in steps 425-445.

[0076] Based on information collected as part of the event or otherwise, the asthma analysis system detects a trigger condition 420. The trigger condition refers to information regarding whether the use was preemptive (e.g., medication taken before exercise) in addition to parameters that may have played a role in triggering the event, the location of the rescue event, a label for the location (e.g., work, home, or school), a rating indicating the personal importance of the location to the patient, and any other relevant information. Examples of trigger conditions include, but are not limited to, a change in the location of the client device, the conclusion of a time period for recording a rescue inhaler use event, a change in the value of at least one patient parameter, weather parameter, and air pollutant parameter, and the occurrence / detection of a rescue inhaler unit dispensing rescue medication.

[0077] In addition to requesting additional event data, the application server 130 accesses stored context data from the database server 140 425. In general, context data refers to data other than event data, including, but not limited to, atmospheric conditions, weather conditions, patient data recorded from past rescue use events, and any other considerations not directly detected by the medication device at the time of the rescue use event. In contrast, event data refers to any parameters related to the rescue event and reported by the medication device, such as dosage, time of the event, location of the event, and associated adherence data. Both forms of data may include information that is current in time, as well as stored historical data. Thus, as part of obtaining the context data, the application server 130 also accesses the patient's 111 past rescue use event data. This historical data may include all data from past controllers, or rescue medication event data from the patient's history over various past time frames, with each historical event including all of the same information items reported for this event, along with data collected at subsequent follow-ups 410.

[0078] However, it should be noted that in some cases in the following description, such as in Figure 6, the context data 635 and the historical data 620 are represented separately. The context data 635 refers to geographic and regional information related to a current event or current location of a patient's client device 110, while the historical data 620 refers to geographic, regional, and event information from previous rescue use events from the same or different patient.

[0079] IV.A. Overview of Asthma Prediction Models FIG. 6 is a block diagram illustrating logical components that perform the functions of the data analysis module 131, according to one embodiment. The asthma analysis system 100 includes a data analysis module 131 on the application server 130 that analyzes various data collected by the system, as introduced above and further discussed below, and performs risk analyses 430 on the patient upon the occurrence of a trigger condition. These risk analyses are used to generate notifications specifically configured to be sent to the patient in a timely manner sufficient to reduce the occurrence of asthma events that require the use of a rescue inhaler. In the illustrated embodiment of FIG. 6, the data analysis module 131 includes a historical data store 620, a parameter value store 630, a model 640, a personalized risk module 650, a classification module 660, a notification module 670, and an interpretation module 680. In other embodiments, the data analysis module 131 may include more or fewer modules. Functions shown to be performed by a particular module may instead be performed by other modules or components.

[0080] The risk analysis may be triggered by a trigger condition, which itself may be automatically scheduled, manually set, and / or occur in response to a particular event or context information. Examples of trigger conditions include, but are not limited to, a change in an input value, a change in a user's location, the result of the occurrence of a rescue event, or the expiration of a time interval.

[0081] To perform the risk analysis, a model 640, such as a mathematical function or other more complex logical structure, is trained using the historical event data and historical context data to determine a set of pre-stored parameter values ​​to be used as part of the risk analysis. The parameter values ​​630 represent "weights" (or critical values ​​or other similar quantities, depending on the modeling technique used) associated with at least one of the input values. The input values ​​refer to numeric or categorical values ​​of the parameters of the model 640, and the input values ​​vary between patients over time.

[0082] Briefly, the risk analysis is performed by inputting aspects of the user's rescue inhaler use events 605, 620 and other contextual data 635, 620 as inputs and parameter values ​​630 into functions of the model 640 to determine a numerical risk score. For example, the model 640 receives as inputs a combination of weather data, pollutant data, patient data, social data, and built environment data, and generates as output a prediction of the number of medication puffs taken by the patient. In general, the contextual data collected for use as inputs (i.e., weather data, pollutant data, patient data, social data, and built environment data) may be collected automatically based on device or other third party data reports, manually provided by the patient and / or provider, or otherwise obtained.

[0083] The expected number of puffs (e.g., the amount of medication dispensed by the rescue inhaler unit) is a numerical value generated by the model 640 that characterizes the expected number of medication use rescue events the patient will experience on that day given the event data 605 and the context data 635. A record of a patient taking a medication puff represents a patient experiencing a rescue medication use event. A prediction of a large number of puffs correlates with an increased number of expected rescue use events, so the prediction of the number of puffs may be interpreted as representative of the patient's asthma risk assessment on a particular day. In an alternative embodiment, the model may instead generate a probability that the patient will experience an expected number of puffs (e.g., a predicted number of rescue inhaler use events) that exceeds a threshold determined for the entire patient population. The patient population may be identified based on the proximity or similarity of their medication use.

[0084] In some implementations, information from the trained model 640 and / or specific inputs and predictions for the user are communicated to an interpretation module 680. The interpretation module 680 performs various processing techniques to further visualize the inner workings of the model 640. These techniques include, but are not limited to, accumulated local effects and permutation-based feature importance at the population level, or Shapley additive explanations at the sample level or individual patient level. Thus, the interpretation module 680 may provide additional insight to the patient or provider as content of notifications generated by the notification module 670, providing a visual explanation of how individual environmental variables affect rescue inhaler use across a patient population, for an individual patient, or for an individual patient's day. FIG. 9A shows an example of a visualization of feature importance, and FIG. 9B shows an example of an visualization of individual variable effects, according to some embodiments.

[0085] The predictions generated by the model are received by the personalized risk module 650 to calculate a patient-specific risk score. In some embodiments, the patient-specific risk score is determined based on a comparison of the raw predictions generated by the model 640 to a recent historical baseline generated for the patient. The historical baseline may be calculated using various techniques to determine a representative distribution of puffs over a period of time. The period over which the historical baseline is calculated may be the set of consecutive days prior to the current day for which the model 640 predicted the expected number of puffs. In another embodiment, instead of the daily predicted number of puffs, the patient's historical baseline may be calculated based on the patient's daily recorded drug use over the previous period of time.

[0086] In one embodiment, the personalized risk module 650 compares the output of the model for the current day (i.e., the predicted number of puffs for the current day) as a percentile of historical predictions of the number of puffs for the previous daily period. In practice, each historical prediction will have some error, but the errors are approximately symmetric in nature, so that the current prediction can be compared to the entire distribution of historical predictions to accurately characterize the patient's risk score.

[0087] In an alternative embodiment, the personalized risk module 650 determines the historical baseline by calculating the standard deviation of the actual historical puffs for each day over the previous period. For example, the personalized risk module 650 calculates a z-score by subtracting the average puffs for the past 30 days and dividing the difference by the standard deviation. The personalized risk module 650 may apply additional computational techniques, such as a sigmoid function, to characterize the patient-specific risk score (i.e., the comparison of the historical baseline to the predicted number of puffs) as a value between 0 and 1.

[0088] In another alternative embodiment, the personalized risk module 650 determines the historical baseline using a bootstrap method: the module first calculates a distribution of sample means based on repeated random samples with replacement from a baseline period of historical puffs per day, and then calculates the expected number of puffs as a percentile of this distribution.

[0089] The patient-specific risk scores generated by the personalized risk module 650 are received by the classification module 660. The classification module 660 classifies the patient-specific risk scores into a range of risk scores, e.g., "good," "fair," or "poor." In some embodiments, the model 640 characterizes the comparison between two days as a fraction comparing the number of doses or a percentile comparing the history of risk scores. For example, a "good" classification may be applied to patient-specific risk scores in the range of 0-3, a "fair" classification may be applied to patient-specific risk scores in the range of 3-9, and a "poor" classification may be applied to patient-specific risk scores in the range of 9+.

[0090] In a particular implementation, model 640 receives air pollutant data indicating that air quality in a particular geographic region poses a significant risk to patients at risk for asthma-related events. Instances of such air pollutant data may be identified using indexes or lookup tables provided by third-party air quality analysis providers or the National Oceanic and Atmospheric Administration (NOAA). In such cases, model 640 implements a combination of rules-based processing techniques to generate and communicate notifications with a "poor" classification to all at-risk patients within the affected geographic region.

[0091] In another implementation, the classification module 660 compares the patient's actual puff count for a given day to a threshold cumulative puff count generated by the personalized risk module 650. The actual puff count may be recorded based on a periodic signal received from a sensor coupled to the patient's rescue use inhaler unit indicating that the inhaler unit has been used to administer a puff. If the actual puff count meets or exceeds the threshold, the classification module 660 classifies the patient-specific risk score as "poor", regardless of the actual numerical value of the risk score for the rest of the day. Such a threshold may be determined based on historical data of rescue use events recorded for the patient over a prior period of time. For example, at a particular time on a particular day for a particular user, the expected number of puffs in a day may be 1.2, which may correspond to a patient-specific risk score of 0.2. A day with a risk score of 0.2 would normally be classified as "good", but because an actual puff count of 4 exceeds the 3 puff threshold, the day is instead classified as "poor".

[0092] IV.B. Implementing Asthma Risk Analysis FIG. 6B illustrates a process for determining a patient's asthma risk using components of the data analysis module 131, according to one embodiment. A model stored in the data analysis module 131, for example model 640, receives as input a combination of weather data, pollutant data, patient data, social data, and built environment data 710. The model is trained to generate as output a prediction of the number of drug puffs taken by the patient on a day corresponding to the received context parameters (i.e., weather data, pollutant data, patient data, social data, and built environment data). Using the model 640, the data analysis module 131 generates a predicted number of puffs that the patient will make on a given day 720. Thus, a higher number of predicted puffs may indicate a higher likelihood that the patient will rescue an asthma use event. The output of the model may also be a binary value (i.e., "0" or "1") representing whether the predicted number of puffs exceeds a population-based threshold, for example, a threshold determined based on data of a population of users included in the dataset on which the model was trained.

[0093] The data analysis module 131 determines 730 a historical baseline based on the patient's asthma-related history. For example, the module 131 may determine the historical baseline based on puff predictions generated by the model for a series of prior days, such as the value of the prior week's predictions. Alternatively, the module 131 may determine the historical baseline based on the patient's actual drug use over a prior period (i.e., how often the patient used their drug device).

[0094] The data analysis module 131 determines 740 a patient-specific risk score by comparing the number of predicted puffs for the current day to a historical baseline. In some embodiments, the patient-specific risk score is a numeric value ranging between 0 and 1. Although the patient-specific risk score is numeric, it may be classified into risk categories. The data analysis module 131 may further compare the patient-specific risk score to a set of threshold ranges between 0 and 1 to classify the patient-specific risk score as either "good," "fair," or "poor" 750. The classification is communicated 760 by the data analysis module 131 to the patient as a notification received via their client device. In addition to the classification of their asthma risk score, the notification also includes recommendations outlining options for the patient to improve their asthma risk.

[0095] IV.C. Model Training With respect to model training and FIGS. 6A and 6B, the model is trained on a training dataset of previous days labeled based on historical data, with each previous day associated with a label based on the historical event data and historical context data recorded during the previous day. In one embodiment, the labels assigned to the previous days of the training dataset represent an indication of the actual number of puffs recorded for the patient on the previous day. As described above, during training of the model 640, a weight is determined for each context parameter value representing the relative importance of each parameter in determining the puff prediction for a particular day. In one embodiment, the weights assigned to the parameters are numbers ranging between 0 and 1, with weights closer to 0 being assigned to less important context parameters and weights closer to 1 being assigned to more important context parameters. During the execution of the model 640 for a given test day, the model 640 (including the weights assigned to each parameter during training) is accessed. For each context parameter, the data analysis module 131 accesses measurements that characterize the context parameter for the given data. Each accessed measurement, also referred to as an input value, is input to the trained model 640.

[0096] To create the training data set used to train the model 640, the data analytics module 131 aggregates or segments the accessed historical data into a period prior to the current day (also referred to as a “trailing window”) to identify input values ​​for various contextual parameters of the model 640. In addition to the set of prior days, the trailing window may also include environmental parameters for the current day. For example, if a patient-specific risk score is calculated at 10:00 AM on day 8, the trailing window may include environmental data, controller usage information, rescue usage information associated with days 1-7, and environmental data recorded cumulatively throughout day 8 between 12:00 AM and 9:59 AM. In another implementation, the trailing window may include environmental data, controller usage information, rescue usage information associated with days 1-7, and current environmental information recorded at 10:00 AM on day 8. For example, environmental information such as air quality and weather data may be obtained from historical datasets from the National Oceanic and Atmospheric Administration (NOAA) and the Environmental Protection Agency (EPA).

[0097] In another embodiment, each day in the training data set is assigned a binary label (e.g., "1" or "0") to indicate whether the number of puffs recorded on that day is above or below a threshold. In such an embodiment, the threshold is a fixed number of puffs set for an entire population of patients, rather than a specific patient. As noted above, in one exemplary implementation, the threshold is determined as the average number of puffs recorded for each patient in the training data set. Thus, a model that receives inputs with binary labels outputs the probability that a patient will experience a number of rescue puffs that exceeds a population-based threshold number of rescue puffs.

[0098] A population-based threshold may be determined based on the total number of puffs recorded for a population of patients during a specified prior period prior to the current day for which the predicted number of puffs is being determined, or the period prior to the time of the current or most recent rescue use event. In one embodiment, the threshold is a portion (percentage) of the total number of use events over a specified period. However, in other embodiments, other functions of the total number of use events may be used to determine the threshold.

[0099] FIG. 8 illustrates a method for training a model 640 using a training dataset, according to one embodiment. The model 640 is trained by determining parameter values ​​630 (e.g., associated with each parameter, not shown) that best represent the relationship between the input values ​​(cells of table A) of the training samples 650 (each row of the table) and the labels (C) of those samples. As introduced above, the model 640 is trained using a function (B) or another more complex logical structure. In one embodiment, the model 640 is trained using machine learning techniques, examples of which include, but are not limited to, linear, logistic, and other forms of regression (e.g., elastic nets), decision trees (e.g., random forests, gradient boosting), support vector machines, classifiers (e.g., naive Bayes classifiers), fuzzy matching, and neural network sequence models (e.g., long short-term memory recurrent neural networks and temporal convolutional networks). An exemplary model 640 trained using a long short-term memory network is described below.

[0100] Once the parameter values ​​are known, model 640 may be used by accessing the parameter values ​​and the function specified by the model and inputting the input values ​​of the parameters to generate an expected number of puffs for a patient on a given day. In embodiments in which the model is trained on a training dataset consisting of days assigned binary labels, model 640 may be used by accessing the parameter values ​​and the function specified by the model and inputting the input values ​​of the parameters to generate a probability that a patient will experience a number of puffs above a threshold on a particular day.

[0101] In the illustrated embodiment of FIG. 8, the training data set (A) includes data describing environmental and patient parameters for the previous seven days and environmental parameters for the current eighth day. Each parameter for each of the eight days is a separate input to the machine learning model (B). Thus, for each day in the training set, the model (B) outputs a numerical value that is assigned a label (C). The label (C) assigned to the model's output for a particular day may be an actual label specifying the number of puffs predicted (i.e., two puffs as shown in FIG. 8) or a binary label specifying the probability that the number of predicted puffs is above or below a threshold number of uses. Moreover, it will be apparent to one skilled in the art that the parameters shown in FIG. 8 are intended to be exemplary without limiting the range of potential parameters.

[0102] IV.D. Input parameters The parameters incorporated into the risk score analysis can be categorized into several groups: past patient parameters, current patient parameters, air pollutant parameters, weather parameters, and context parameters. The past and current patient parameters may be more broadly categorized as simply "patient parameters." The air pollutants and weather variables may be more loosely categorized as "environmental condition parameters." The numerical values ​​of the parameters are taken into account in the form of input values ​​to the generated functions, as described above. Further, from the parameters, parameter values ​​of the model 640 are derived.

[0103] Past patient characteristics include, but are not limited to, cumulative patient history of rescue events over a period of time, rescue unit used, Taru product Number of days , disease type, such as asthma or COPD, a record of rescue events that occurred during the night, and a controller medication adherence record. The patient history of rescue events may include information related to the above categories regarding previous rescue events. The disease type represents the severity of the patient's asthma and their personal treatment plan. The controller medication adherence record includes information about the patient's use of their controller medication (which may also be associated with the sensor unit 160). This determination is evaluated by observing when usage is prescribed but not followed, when usage is prescribed and followed, and when usage is not prescribed but followed.

[0104] The current patient characteristics may include, but are not limited to, the current latitude, longitude, and location of the client device 110 coordinates, as well as the current date. The current latitude and longitude are used to determine the patient's geographic location, from which information about the patient's environmental conditions can be determined. The current rescue event data may include, but is not limited to, the current patient characteristics. , Re Skew Puff's Usage times number and prescription times The current rescue event data may also include time data indicating a timestamp associated with the rescue use event, such as the month, day of the week, or time of the day that the rescue use event occurred.

[0105] The characteristics of air pollutants may include information regarding concentration (e.g., analog values) or a binary indication of the presence or absence of the pollutant on the ground, in the air, or a combination of both. Examples of pollutants considered include, but are not limited to, carbon monoxide, ozone molecules, nitrogen dioxide molecules, sulfur dioxide molecules, particulate matter with a size of 2.5 micrometers or less, particulate matter with a size of 10 micrometers or less, and airborne pollutants. temperament Specific weather characteristics include temperature, humidity, wind speed, wind direction, current location Air pressure, visual Process may include.

[0106] Context parameters indicate social information about the patient, the patient's living conditions, or the environment. Examples of context parameters include, but are not limited to, socio-economic factors, demographic factors, built environment factors, land use factors, and behavioral health factors.

[0107] In some embodiments, the context parameters also include social data capturing social trends and user behavior data, e.g., asthma searches, for an area based on trends or commonalities in patient behavior. For example, an area where a large proportion of users perform Google searches or alternative internet-based searches related to asthma treatment is associated with a higher risk of asthma rescue use events. As another example, an area associated with a sudden increase in sales of inhaler rescue units in a particular time period may be associated with a higher risk of asthma rescue use events. Thus, such social data (i.e., social trends and user behavior data) for an area at a given time may be input into the model 640 to determine the predicted number of daily puffs that will occur during that time. When recorded by the asthma analysis system 100, some parameters, e.g., air pollutant parameters, weather parameters, and patient parameters, are associated with a timestamp that indicates the temporal details of the day the parameters were recorded. In one embodiment, the timestamp includes specific details that indicate the parameter, e.g., the time of day, the day of the week, and its relationship to other parameters recorded during that timestamp. In an alternative implementation, each parameter may be associated with a successive timestamp that indicates the time the parameter was recorded compared to parameters recorded during other timestamps.

[0108] Of all the aforementioned air pollutant features, weather features, and current patient features, the model 650 may select certain features to be considered when determining the patient's risk score. Certain features may be combined into aggregate features that provide greater predictive value. For example, latitude and longitude data may be interpreted as information indicative of the client device 110's climate region, state, or city. In other embodiments, the current location of the client device 110 may be compared to the location of a point of interest (i.e., a location or area determined to be associated with the user or healthcare provider) to determine the distance required to travel from the current location to the point of interest. The particular combination of features selected by the model 650 may be adjusted during a training period or updated repeatedly over a period of time.

[0109] IV.E. Long Short-Term Memory (LSTM) Network Example Since the risk of a rescue use event is not only dependent on the current contextual data, but may also be related to some degree to previously occurring contextual data, some embodiments of model 640 reflect such a temporal component. In one such embodiment, model 640 is a long short-term memory (LSTM) network. Long short-term memory networks, a subclass of recurrent neural networks, can take into account the temporal nature of said data by using LSTM cells that sequentially process each time step of the input data array. The LSTM cell itself contains a number of hidden layers or "gates" that interact in various ways to generate two intermediate output vectors, the hidden state and the cell state. These two intermediate output vectors, designed to persist latent information relevant to the generation of the final risk score, are input into the cell along with the next time step of the input data. After the last time step of the input data, the final hidden state of the cell is then output to the remainder of the LSTM network, which is comprised of one or more layers that generate the final risk score as an output.

[0110] Each layer in the network contains nodes, each of which performs a function on either the input data or intermediate outputs of the previous layer. This function typically involves multiplication with trainable weights and a nonlinear activation function. Using a variation of gradient descent with an appropriate cost function, errors can be propagated through the network and through each time step of the cell to update the weights appropriately after each batch sample.

[0111] The exemplary model includes hidden and cell states of vector size 128, with 7 days of time data, past context data, and past patient data passed after the dense layer with a dropout rate of 0.3. The sample model can be trained with a binary cross-entropy cost function using an Adam optimizer with learning rate=0.001, beta_1=0.9, and beta_2=0.999. In another embodiment, the optimal architecture of the model is updated periodically whenever the model receives new time data. Such architecture and hyperparameter updates can be performed using a Bayesian optimization tool implemented by Amazon Web Services' SageMaker product.

[0112] In an embodiment in which the model 640 is an LSTM, the data analysis module 131 accesses the patient data recorded over a period of time. The accessed patient data may be further sorted into individual time steps, with each time step representing a rescue inhaler use event. The data analysis module 131 encodes the patient data (including at least the patient parameters, the weather parameters, and the air pollutant parameters) of each rescue inhaler use event into a feature vector (hereinafter referred to as a parameter vector). Each feature value of the parameter vector represents the value of the patient parameter, the weather parameter, or the air pollutant parameter recorded at the time of the rescue inhaler use event. The time at which the rescue inhaler use event is detected may hereafter be referred to as a "time step." In some embodiments, a daily or hourly timestamp may be recorded during each instance in which a rescue inhaler use event is detected.

[0113] The data analysis module 640 iteratively inputs each parameter vector into the model, since each parameter vector is an encoded representation of parameter values ​​measured at a distinct time step. The model 640 iteratively updates the intermediate output vector for each time step occurring over a period of time based on the parameter vector encoding the parameter values ​​recorded over the time step and the intermediate output vector determined for the previous time step. As an illustrative example, at a first time step T1, the model 640 receives as input a parameter vector P1 representing the parameter values ​​recorded at T1 and outputs an intermediate output vector I1. At a second time step T2, the model 640 receives as input a parameter vector P2 and an intermediate output vector I1 representing the parameter values ​​recorded at T2 and outputs an updated intermediate output vector I2. Thus, the model 640 iteratively receives the parameter vectors of the time steps preceding the current time step to generate a final output vector (e.g., a current output vector) that provides a potential representation of a sequence of parameter values ​​associated with rescue inhaler use events occurring over a period of time leading up to the current time step. The current output vector is input to a personalized risk module 650 to determine the patient's risk score at the current time step.

[0114] IV.F. Asthma Rescue Event Risk Notification The notification module 645 generates 435 a risk score notification including any one or more of the classification, the patient-specific risk score, the predicted number of puffs, potential causes of the risk score and the predicted number of puffs, and options the patient may take under these circumstances to prevent another rescue use event from occurring. As discussed above, the application server 130 generates 435 a risk score notification to one or more of the patients 111, their healthcare providers 112, and / or other authorized individuals.

[0115] The risk notification may include a wide variety of information content, including risk scores, classifications, and any input values ​​from any parameters of the model 640.

[0116] The risk communication may also consist of recommendations on how to prevent future rescue inhaler events based on the parameters that caused the change in risk classification. For example, recommendations may include following the adherence schedule more closely, increasing the dosage or use of the controller medication, avoiding the geographic area altogether, or limiting exposure to areas with similar environmental conditions.

[0117] Additionally, the patient 111 may be provided with a geographic map that includes pinpoints of the locations of all medication rescue events that occurred in the last year. As another example, the patient 111 may be provided with a geographic map that includes pinpoints of where the event 410 occurred and all medication rescue events that occurred in a nearby geographic area within that day or threshold time period, showing recent patterns of medication rescue events in that area. As another example, the patient's 111 health care provider 112 may be presented with medication rescue event data from the patient 111 from that day or recent time period to help the provider 112 identify trends in medication rescue events.

[0118] Risk notifications may also be delivered in many other circumstances, which may be based on trigger conditions or sent to the client device according to other mechanisms depending on the implementation. For example, an updated risk notification is delivered to the patient 111 if the patient's current condition worsens due to a change in a patient parameter (e.g., decreased patient controller medication adherence) or an environmental condition parameter (e.g., low levels of ozone, increased amounts of pollutants in the air, or increased humidity). As noted above, in another implementation, a risk notification may be presented to a patient when the patient-specific risk score increases or when the risk score is reclassified, for example, from "fair" to "poor." In additional implementations, notifications of patient-specific risk scores or classifications may be presented to health care providers to inform staffing, medical supplies, or describe the medical condition of a clinic or group of patients. Alternatively, an updated risk notification may be delivered if the patient's current condition improves due to a similar change. Risk notifications may also be delivered upon request of the patient, for example, by a verbal request for local asthma status from a third-party device (e.g., Google Home® or Amazon Alexa®).

[0119] As noted above, typically risk notifications are delivered via the client device 110, however in other embodiments, if the condition improves or worsens, the risk notifications may be delivered as SMS notifications, email notifications, notifications from an embeddable widget with local asthma status, or notifications from various IFTTT applets (https: / / ifttt.com / ).

[0120] V. Example VA Example 1 7A shows an example of a receiver operating characteristic curve on an unseen, forward-looking test set. A baseline model 650 implementing an LSTM network achieved an area under the receiver operating characteristic curve of 0.90, thereby validating the effectiveness of the LSTM-implemented model.

[0121] VB example 2 Figure 7B shows an example of precision-recall curves for an unseen, forward-looking test set. The baseline model 650 implementing an LSTM network achieved an area under the receiver operating characteristic curve of 0.72, thereby validating the effectiveness of the LSTM-implemented model.

[0122] VI. Advantages The asthma rescue event risk notification provided to the patient 111 and provider 112 conveys many benefits. The patient is notified in real-time or near real-time (on the order of seconds to minutes) of the risk of an asthma rescue event and can take steps to prevent its occurrence, for example, by improving adherence to controller medication, moving away from areas with adverse conditions (e.g., air pollution concentrations), reducing the frequency of the patient's emergency room or hospital visits by adding or modifying a prescribed medication regimen (such as adjusting dosages or introducing antibiotics or systemic corticosteroids), or scheduling an appointment with a physician to address a recent spike in rescue medication use. Because the event data is automatically reported to the application server 130 without requiring patient input, the accuracy and quality of the event data is improved compared to data manually collected by the healthcare provider 112 or other entities, and therefore the outcomes regarding the risk of an asthma rescue event are also improved.

[0123] Additionally, follow-up notifications provided by the application server 130, including reports of nearby rescue medication events by other patients, can provide the patient with additional information about others suffering from similar issues and provide local information regarding the patient's decision-making. The follow-up notifications can further encourage the user regarding progress in medication adherence. Ideally, such notifications would prevent asthma rescue events from occurring, thus preventing harm to the patient, as well as hospital visits and their associated costs.

[0124] A healthcare provider who is informed of one or more patients' risk of an asthma rescue event can similarly track the patient's progress and use the information to update each patient's treatment plan or schedule appointments with the patient. For patients at high risk of an asthma rescue event, the notification can be a call to action for the healthcare provider to contact the patient and encourage them to seek treatment. Follow-up notifications can provide information about local influences (e.g., pollution), patient controller adherence, etc.

[0125] VII. Additional Considerations Although the above description focuses specifically on asthma, all of the systems and processes described herein are equally applicable to chronic obstructive pulmonary disease (COPD) and chronic respiratory diseases (CRD), and as a result may be used to aid in the treatment of COPD and CRD, as well as asthma.

[0126] It should be understood that for clarity, the figures and descriptions of the present disclosure have been simplified to illustrate elements relevant to a clear understanding of the present disclosure, while excluding many other elements found in a typical system. Those skilled in the art may recognize that other elements and / or steps are desirable and / or necessary in implementing the present disclosure. However, because such elements or steps are well known in the art and do not facilitate a better understanding of the present disclosure, a discussion of such elements and steps is not provided herein. The disclosure herein covers all such variations and modifications to such elements and methods known to those skilled in the art.

[0127] Some portions of the above description describe embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to effectively convey the substance of their work to others skilled in the art. While these operations have been described functionally, computationally, or logically, they will be understood to be implemented by computer programs, or equivalent electrical circuits, microcode, or the like. Further, without loss of generality, it will prove convenient at times to refer to arrangements of these operations as modules. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combination thereof.

[0128] As used herein, a reference to "one embodiment" or "an embodiment" means that the particular element, feature, structure, or characteristic described in connection with this embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment.

[0129] As used herein, "comprises," "comprises," "includes," "including," "has," "having," or any other variation thereof, is intended to include a non-exclusive inclusion. For example, a process, method, provision, or apparatus that comprises a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent in such process, method, provision, or apparatus. Furthermore, unless expressly stated otherwise, "or" refers to an inclusive "or" and not an exclusive "or." For example, a condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exists).

[0130] Furthermore, the use of "a" or "an" is employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. The description includes one or at least one, and the singular should be read to include the plural, unless it is clear that this is not meant.

[0131] While particular embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise structure and components disclosed herein. Various modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope as defined in the appended claims.

Claims

1. A method for determining a priming operation of a medication device sensor, the method comprising: identifying an operational status of a rescue inhaler unit; accessing a sequence of parameter vectors corresponding to time steps occurring over a period of time for a patient, each parameter vector of the sequence including a set of values ​​describing at least one patient parameter, a weather parameter, and an air pollutant parameter recorded by the medication device sensor during a rescue inhaler usage event, the medication device sensor being removably attached to the rescue inhaler unit and configured to monitor medication usage of the rescue inhaler unit as the rescue inhaler unit dispenses rescue medication to the patient; inputting the sequence of parameter vectors into a machine learning model to generate a current output vector that provides a latent representation of the sequence of parameter values ​​associated with rescue inhaler use events occurring over the period of time, the machine learning model comprising: iteratively updating an output vector for each time step occurring over the period based on a corresponding parameter vector to generate a current output vector at the current timestamp based on the parameter vector for a current time step, where the output vector is calculated for a time step immediately preceding the current time step; determining a predicted number for a number of rescue puffs in a rescue inhaler use event for the current time step based on the current output vector; wherein the machine learning model is trained with training data over a historical period that is labeled based on historical data recorded by the medication device sensors during rescue inhaler use events; determining a historical baseline based on the standard deviation for the number of rescue puffs in the daily records of medication use by the patient over the historical period or the rescue inhaler use events recorded during the historical period; inputting the predicted number of rescue inhaler use events into a function, the function comparing the predicted number of rescue inhaler use events for the current time step to the historical baseline; determining a risk score for the current time step based on the comparison; and establishing a network connection between the medication device and a client device in response to the medication device sensor determining the priming action; sending a risk notification to the client device operated by the patient, the risk notification indicating the risk score determined for the current time step, the risk notification being delivered as an SMS notification, an email notification, or a notification from an embeddable widget having a local asthma status, the risk notification including a display card on a display of the client device configured to receive an input response; A method comprising:

2. receiving a record of rescue inhaler usage events occurring over the period of time from the client device, the medication device sensor, or the rescue inhaler unit; The method of claim 1 further comprising:

3. inputting the current output vector into the function to determine a risk score for the current time step according to a trigger condition, the trigger condition being: A change in the physical location of the client device; the end of said period; A change in the value of at least one patient parameter, meteorological parameter, and air pollutant parameter; and an occurrence of a rescue inhaler use event during the current time step detected when the rescue inhaler unit dispenses rescue medication to the patient during the current time step; One or more of The method of claim 1 further comprising:

4. The method of claim 1 , wherein the machine learning model is a long short-term memory neural network.

5. The method of claim 1 , wherein the risk score is a numerical value representing the likelihood that the patient will experience a rescue inhaler use event during the current time step.

6. The method of claim 1 , wherein the set of values ​​further comprises at least one event data parameter and at least one context data parameter.

7. The set of values ​​is: cumulative patient history of rescue events; Patient history of events that occurred during the night; the cumulative number of days the rescue inhaler unit was used; type of disease, and Compliance record Further comprising: At least one historical patient parameter [0033] the compliance record includes information regarding the patient's use of a controller medication; The method of claim 1.

8. The set of values ​​is: the current latitude and longitude coordinates of the client device; Current location, The current date, and Difference in the number of rescue puffs used and the number of prescriptions given for the rescue inhaler use event Further comprising: At least one current patient parameter The method of claim 1 , comprising one or more of:

9. The set of values ​​is: Ozone molecule (O3), Carbon monoxide molecule (CO), Nitrogen dioxide molecule (NO2), Sulfur dioxide molecules (SO2), Particulate matter smaller than 2.5 micrometers (PM2.5), Particulate matter smaller than 1 micrometer (PM1.0), and Air quality index (AQI) Further comprising: At least one air pollutant parameter The method of claim 1 , comprising one or more of:

10. The set of values ​​is: temperature, humidity, wind speed, wind direction, Local air pressure, and Visibility Further comprising: At least one meteorological parameter The method of claim 1 , comprising one or more of:

11. The set of values ​​is: Social parameters of the geographical area, and Geographical region behavior parameters 13. The method of claim 1, wherein the geographical region includes one or more of:

12. 2. The method of claim 1, wherein the set of values ​​includes a number of days for which rescue inhaler use events are monitored by a computing system external to the rescue inhaler unit.

13. 2. The method of claim 1, wherein the machine learning model determines whether a number of rescue inhaler use events for a given day exceeds a threshold based on the output of the function.

14. The method of claim 1 , wherein the risk notification is presented at a time step following the current time step at which the risk score was determined.

15. 2. The method of claim 1, wherein the risk notification includes information content regarding a trigger condition, the trigger condition being set based on automatic scheduling, manual setting, and / or occurrence in response to a specific event or context information.

16. The risk notification may include: a record of rescue inhaler use events occurring over a period of time; a threshold against which the risk score was compared; and Risk classification based on the risk score and information content relating to at least one of The recording of the rescue inhaler use event is performed by the medication device sensor during the rescue inhaler use event, the threshold is determined as a fixed number of rescue puffs for an entire population of patients included in a training dataset of the machine learning model, and the risk classification is generated as a classification result of the risk score. The method of claim 1.

17. The method of claim 1, wherein the risk notification further comprises information content relating to the rescue inhaler use event, the information content further comprising a subset of patient parameters, meteorological parameters, and air pollutant parameters that contribute to a change in risk classification compared to a previous period, the risk classification being generated as a classification result of the risk score and being changed based on changes in parameters within the subset, and the subset being associated based on a timestamp indicating temporal details at which the rescue inhaler use event was detected.

18. The method of claim 1, wherein the risk notification further includes information content related to the rescue inhaler use event, the information content further including a recommendation on how to prevent future rescue inhaler use events based on a subset of patient parameters, weather parameters, and air pollutant parameters that contribute to a change in risk classification.

19. A non-transitory computer-readable storage medium that, when executed by a computer processor, causes the computer processor to: determining a priming operation of the medication device sensor, including identifying an operational status of the rescue inhaler unit; accessing a sequence of parameter vectors corresponding to time steps occurring over a period of time for a patient, each parameter vector of the sequence including a set of values ​​describing at least one patient parameter, a weather parameter, and an air pollutant parameter recorded by a medication device sensor during a rescue inhaler usage event, the medication device sensor being removably attached to a rescue inhaler unit and configured to monitor medication usage of the rescue inhaler unit as the rescue inhaler unit dispenses rescue medication to the patient; inputting the sequence of parameter vectors into a machine learning model to generate a current output vector that provides a latent representation of the sequence of parameter values ​​associated with rescue inhaler use events occurring over the period of time, the machine learning model comprising: iteratively updating an output vector for each time step occurring over the period based on a corresponding parameter vector to generate a current output vector at the current timestamp based on the parameter vector for a current time step, where the output vector is calculated for a time step immediately preceding the current time step; determining a predicted number for a number of rescue puffs in a rescue inhaler use event for the current time step based on the current output vector; wherein the machine learning model is trained with training data over a historical period that is labeled based on historical data recorded by the medication device sensors during rescue inhaler use events; determining a historical baseline based on the standard deviation for the number of rescue puffs in the daily records of medication use by the patient over the historical period or the rescue inhaler use events recorded during the historical period; inputting the predicted number of rescue inhaler use events into a function, the function comparing the predicted number of rescue inhaler use events for the current time step to the historical baseline; determining a risk score for the current time step based on the comparison; and establishing a network connection between the medication device and a client device in response to the medication device sensor determining the priming action; sending a risk notification to the client device operated by the patient indicating the risk score determined for the current time step, the risk notification being delivered as an SMS notification, an email notification, or a notification from an embeddable widget having a local asthma status, the risk notification including a display card on a display of the client device configured to receive an input response; A non-transitory computer-readable storage medium comprising computer program instructions for causing a

Images