JP2020536338A - Preemptive asthma risk notification based on drug device monitoring - Google Patents

Abstract

The present specification provides asthma risk notifications prior to those events to help influence changes in patient behavior to prevent the occurrence of predicted rescue utilization events. Rescue drug events, changes in environmental conditions, and other contextually relevant information are detected by sensors associated with the patient's drug device / to provide a basis for determining the patient's risk score, respectively. , Collected from other resources. This data is analyzed to determine the severity of a patient's risk to an asthma event and is used to send notifications accordingly.

Description

The disclosure relates generally to methods of improving treatment for patients using inhalers, and more specifically to determining the risk of asthma-related rescue events in patients.

Asthma remains an important and costly public health problem. Globally, the World Health Organization estimates that the population with asthma can reach 300 million, and that population will grow to 400 million by 2025. In the United States, asthma affects one in twelve people in the United States, and the number of patients is on the rise, causing more than $ 56 billion in health care costs annually.

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 outpatient visits, 500,000 hospitalizations, and 5,000 deaths. In addition, asthma is responsible for an estimated 15 million school holidays and 12 million absenteeism. The total annual cost to US health insurance companies and health insurance employers exceeds $ 18 billion.

Most of these exacerbations can be prevented with currently available treatments, but only one in five asthma patients manages the disease. Newly revised national guidelines require doctors to more closely monitor whether treatment manages daily symptoms and improves quality of life. However, physicians have few tools available to assess how well their patients are doing each day. More and more physicians have begun to use periodic descriptive questionnaires (such as asthma management tests) to monitor patients and determine their level of control. These measures require the patient to accurately recall and report on the frequency of symptoms, inhaler use, and activity level, as well as constraints over a period of time (typically 2 to 4 weeks). As a result, these questionnaires are prone to errors caused by biased judgment (recollection), different interpretations of symptoms, and behavior (non-adherence), and only when these questionnaires are used. Provide information about.

More generally, drug devices such as inhalers allow patients to manage respiratory symptoms such as suppressed air flow. Many patients with respiratory illness, such as those with asthma, chronic obstructive pulmonary disease (COPD), and cystic fibrosis, have symptoms of environmental triggers and factors such as air environment, weather, and land use. Recognizing which environmental triggers and factors affect the condition allows the patient to better manage the condition and reduce the chances of needing emergency medical care. However, a particular patient or group of patients can be sensitive to multiple triggers and factors. Knowing which of the tens, hundreds, or more of triggers and factors a patient is sensitive to and monitoring those triggers and factors for use in symptom management is complex. It is a task and is not currently feasible for many patients and providers.

U.S. Patent Application No. 12 / 348,424 International Application No. PCT / US2014 / 039014

http://xgboost.readthedocs.io/en/latest/python/python_api.html

The asthma analysis system is an integrated platform for treating, monitoring and managing rescue events caused by asthma. An asthma analysis system receives an event notification from a sensor attached to a drug device (eg, an inhaler) used by a patient who has allowed the asthma analysis system to help manage its asthma. To track. The sensor records the geographic location, time, and date of rescue utilization events when attached to or integrated into a dose inhaler or other drug device, and asthmaizes that information. Communicate with the analysis system. The asthma analysis system analyzes incoming events (both recent and previous received events) in real-time or near-real-time, risk assessment, and informs patients and healthcare to guide and manage disease. Deliver to the provider.

The risk score is determined using a combination of parameters including the patient's medical history, the patient's daily status, and environmental conditions with respect to air and weather conditions. The relationship between these parameters and the risk assessments generated for the patient is embedded within the machine learning model. The model, and more generally, the system receives input values for the parameters and classifies the patient's risk score to provide a risk assessment along with accurate and medically relevant treatment options to mitigate risk. It is possible to (categorize).

By incorporating information about the timing, frequency, and location of drug use, along with other contextually relevant parameter information, the asthma analysis system can make immediately applicable changes in behavior or environment prior to those predictive events. By suggesting, it helps prevent the occurrence of future asthma rescue utilization events. This facilitates better management of asthma treatment by patients and their healthcare providers and improves awareness of specific locations that trigger rescue events so that patients can avoid or respond to these locations in the future. ..

According to one embodiment, a method for determining the risk of an asthma-related rescue event for a patient comprises accessing past rescue inhaler utilization events for a set of patients. A set of events has been previously received from an attachment associated with a client device or rescue inhaler unit, or from a rescue inhaler unit that provided a rescue drug to a patient as part of each event. The method also includes the step of determining a patient-specific baseline risk threshold based on a set of events. Depending on the trigger condition, this method includes accessing a set of parameter values for the model for predicting asthma risk and accessing a set of input values. Again, depending on the trigger condition, this method involves entering parameter values, input values, and baseline risk thresholds into a function for determining the risk score. Depending on the trigger condition, this method involves sending a notification to the device with risk score details.

In one or more embodiments, the method also includes the step of receiving a history of rescue inhaler utilization events from a client device, attachment, or rescue inhaler unit.

In one or more embodiments, the threshold is determined for a previous period that includes an event from a time window that precedes the current time.

In one or more embodiments, the threshold is determined as a percentage of the sum of the events in the previous period.

In one or more embodiments, the threshold is determined cyclically.

In one or more embodiments, the trigger condition includes a threshold change in the physical position of the client device.

In one or more embodiments, the trigger condition comprises a periodic conclusion of the time interval.

In one or more embodiments, the trigger condition comprises changing the threshold of at least one input value of the parameters.

In one or more embodiments, the trigger condition is received from the client device, attachment, or rescue inhaler that provided the patient with rescue medication as part of the current rescue inhaler utilization event, the occurrence of the current event. including.

In one or more embodiments, the parameter values are determined using a boosted gradient model.

In one or more embodiments, the risk score is a numerical value that represents the likelihood that the patient will exceed the threshold for the day.

In one or more embodiments, the parameter comprises at least one event data parameter and at least one context data parameter.

In one or more embodiments, the parameters further include a cumulative patient history of rescue events, a patient history of events that occur at night, a cumulative count of days using the rescue unit, disease type, and adherence records, at least one. Includes two past patient parameters.

In one or more embodiments, the parameters are the current longitude and latitude coordinates of the client device, the current position, the current date, and the number of rescue puffs taken and prescribed for the rescue event. Includes at least one current patient parameter, further including the difference in.

In one or more embodiments, the parameter further comprises an ozone molecule, a nitrogen dioxide molecule, a sulfur dioxide molecule, a particulate matter of 2.5 micrometers or less, a particulate matter of 1 micrometer or less, and an air quality index, at least one. Includes air pollutant parameters.

In one or more embodiments, the parameter comprises at least one meteorological parameter, further including temperature, humidity, wind speed, wind direction, air pressure, and visibility.

In one or more embodiments, the parameters are temperature, relative humidity, wind velocity parameters, nitrogen dioxide (NO ₂ ), sulfur dioxide (SO ₂ ), particulate matter less than 2.5 micrometers (PM _2.5 ), and 1 micrometer. Contains one or more of the following particulate matter (PM _1.0 ):

In one or more embodiments, the parameter includes the number of days that the rescue inhaler utilization event is monitored by a computing system external to the rescue inhaler unit.

In one or more embodiments, this function determines whether the number of rescue inhaler utilization events for a given date exceeds the threshold.

In one or more embodiments, the risk notification is presented at a first time that is different from the second time at which the risk threshold is determined.

In one or more embodiments, the risk notification includes information content about the trigger condition.

In one or more embodiments, the risk notification includes informational content about at least one of the event, baseline risk threshold, and risk classification based on the risk score.

In one or more embodiments, the risk notification further includes information content about the rescue event, which further includes a subset of parameters that cause a change in the risk classification compared to the previous time period.

In one or more embodiments, the risk notification further includes informational content about the rescue event, the informational content further includes recommendations on how to prevent further rescue inhaler events, and the recommendations include changes to the risk classification. Based on a subset of the parameters that cause.

FIG. 5 illustrates an asthma analysis system for monitoring accurate real-time drug device use, performing analysis on the data, and providing asthma rescue event risk notification according to an embodiment. FIG. 6 is a high-level block diagram illustrating an example of a computing device used in any of a client device, an application server, and / or a database server according to an embodiment. FIG. 5 illustrates a dashboard of a client application that allows a user to interact with an asthma analysis system, according to an embodiment. It is a figure which shows one example card which is displayed in the dashboard of the client application by one Embodiment. It is a dialogue diagram for providing asthma risk-based notification based on drug device monitoring according to one embodiment. It is a flowchart for detecting a rescue drug event by an asthma analysis system according to one Embodiment. It is a block diagram which shows the module in the asthma risk score module by one Embodiment. It is a block diagram which shows the training module which is implemented by the asthma risk score module by one Embodiment. It is a figure which shows the method for training a model using a training data set by one Embodiment. It is a figure which shows the method of establishing the threshold value for risk identification by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment. It is a figure which characterizes and analyzes the data used for testing the asthma risk analysis by one Embodiment.

The figures show various embodiments of the invention presented, for illustration purposes only. Those skilled in the art will readily recognize from the following discussion that other embodiments of the structures and methods described herein may be adopted without departing from the principles described herein.

I. System Environment Figure 1 shows an asthma analysis system 100 for monitoring accurate real-time drug device events, performing analysis on the data, and providing asthma rescue event risk notifications, according to an embodiment.

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. Figure 1 shows only a single case of most of the components of the asthma analysis system 100, but in practice there can be more than one of each component, with additional or fewer components used. Can be done.

IA client device and application The client device 110 interacts with the asthma analysis system 100 over the network 150 at the direction of its user. For illustration and clarity, it is useful to identify at least two different types of users. Patient 111, at least in part, uses the asthma analysis system 100 to obtain personalized asthma rescue event risk notifications provided by server 130 and asthma management notifications produced by its healthcare provider 112. A user who suffers from asthma. Such notification may be provided in exchange for the user's permission to allow the asthma analysis system 100 to monitor the drug device 160 utilization of patient 111. As described below, the drug event is detected by the sensor 120 associated with the drug device 160 and the user's client device 110, which in turn reports to the application server 130, which in turn reports to the application server 130. The process for generating risk notifications provided to the user through the client device 110 may be initiated.

Another type of user, again with the special permission of patient 111, provides notifications regarding patient asthma management, asthma community rescue event data, and statistics derived for asthma events, and other relevant data. The medical provider 112 who also receives. Other types of users, such as parent / protection of patient 111, may also wish to receive notifications if their own client device 110 is different from its child client device 110.

The client device 110 is a computer system. One exemplary physical implementation is described more fully below with respect to FIG. The client device 110 is configured to communicate wirelessly with the asthma analysis system 100 over the network 150. With network 150 access, client device 110 describes the user's geographic location and the time of the rescue drug event, as well as the event received from the associated drug device sensor 120 (referred to herein as "sensor 120"). Send information to system 100.

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

In addition to communicating with the application server 130, the client device 110 wirelessly connected to the asthma analysis system 100 can also exchange information with other connected client devices 110. For example, through the client software application 115, healthcare provider 112 receives a risk exacerbation notification explaining a recent rescue event for patient 111, and then accordingly sends a recommendation for treatment after the asthma rescue event to patient 111. can do. Similarly, through application 115, patient 111 can communicate with its healthcare provider 112 and other patients 111.

The application 115 is displayed on the screen of the client device 110 and is a user interface (referred to herein as a "dashboard") that allows the user to enter commands to control the operation of the application 115. I will provide a. The dashboard is the mechanism by which healthcare providers 112 and patients 111 access the COPD analysis system 100. For example, the dashboard allows patients 111 and donors 112 to interact with each other, receive asthma rescue event risk notifications, exchange treatment messages, provide and receive additional event and non-event data, and so on. to enable. Application 115 may be coded as a web page, a set of web pages, or, in some cases, content coded for rendering within an internet browser. Application 115 may be coded as a claimable application configured to run on the native operating system of client device 110. The dashboard is described more fully below in relation to Figure 3.

In addition to providing a dashboard, application 115 uses the resources of client device 110 locally to perform some data processing on the asthma rescue event data before sending the processing data over network 150. You can also. The event data transmitted via the network 110 is received by the application server 130, where the event data is analyzed and processed for storage and retrieval in cooperation with the database server 140. The application server 130 can directly retrieve the request and store it in the database system 130 in response to the request of the client application 115.

The client device 110 communicates with the sensor 120 using either a wired communication protocol or a wireless communication protocol, the network adapter, and one example of which is the Bluetooth Low Energy (BTLE) protocol. BTLE is a short-range, low-power protocol standard that wirelessly transmits data over wireless links within short-range wireless networks. After the sensor 120 and the client device 110 are paired with each other using the BTLE passkey, the sensor 120 automatically synchronizes and communicates information about drug device utilization with the client device 110. If the sensor 120 is not paired with the client device 110 prior to the rescue drug event, the information is stored locally until such pairing occurs. As soon as it is paired, the sensor 120 communicates any stored event record to the client device 110. In other implementations, other types of wireless connections are used (eg infrared or 802.11).

The client device 110 and the drug device 160 are described above as separate physical devices (such as smartphones and inhalers, respectively), but in the future the drug device 160 will be integrated into a single housing with the device 160. It is contemplated that not only the sensor 120 but also the aspect of the client device 110 may be included. For example, the drug device 160 may include an audiovisual interface that includes a display or other lighting element as well as a speaker for presenting visual audible information. In such an implementation, instead of or in addition to presenting the content of the notification provided directly by the server 130 through the client device 110, the drug device 160 itself may present them.

IB Drug Device and Sensor Drug Device 160 is a medical device used to deliver a drug to the lungs of a user experiencing suppressed respiratory air flow. Drug devices (eg, inhalers) are generally portable and small enough to be carried by hand for easy access when treating a respiratory attack. In one embodiment, the drug is delivered in spray form through a drug device 160, such as a fixed dose inhaler. The fixed dose inhaler also holds a pressurized injection canister for the spray, a control valve for delivering a regulated dose amount, and a mouthpiece for holding the pressurized canister and delivering the drug. Includes a plastic holder to form. In another embodiment, the drug is delivered in the form of dry powder through a drug device 160, such as a dry powder inhaler. The dry powder inhaler may have a Cartesian ovular shape containing a gear mechanism that allows the user to index strips of dry powder drug. The body of the dry powder inhaler also includes a manifold and mouthpiece for delivering the dry powder to the user. Examples of controller medications administered by the long-term management drug device 160 include beclomethasone, budesonide, and fluticasone, as well as combinations of those drugs with long-acting bronchodilators such as salmeterol or formoterol. There is. Examples of rescue drugs administered by the rescue drug device 160 include albuterol, salbutamol, levalvterol, metaproterenol, and terbutaline.

Each patient can be associated with more than one drug device 160. For example, a patient may have a rescue drug device 160 that administers a rescue drug and a long-term management drug device 160 that administers a long-term management drug. Similarly, each patient may be associated with two or more sensors 120, each selected to act with one of the patient's drug devices 160.

In general, the sensor 120 is a physical device that monitors the utilization of the drug dispenser 160. The sensor 120 is detachably attached to the drug dispenser without interfering with the operation of the drug dispenser, or the sensor 120 is an integrated configuration that is the original part of the drug dispenser 160 as made available by its manufacturer. It is a part.

The sensor 120 includes its own network adapter (not shown) that communicates with the client device 110 through a wired connection, or more generally, a wireless radio frequency connection. In one embodiment, the network adapter is Bluetooth Low Energy (BTLE) wireless transmission, but in other embodiments, other types of wireless communication may be used (eg, infrared, 802.11).

The sensor 120 may be configured to communicate more directly with the application server 130. For example, if the network adapter for sensor 120 is configured to communicate over a wireless standard, such as 802.11 or LTE, the adapter can exchange data with a wireless access point, such as a wireless router, and the wireless access point. Can communicate with the application server 130 without necessarily requiring the client device 110 for any exchange of data. These two communication methods are not mutually exclusive, and the sensor 120, for example, to ensure that the event data arrives at the application server 130, or what the application server 130 does, depending on the event. Redundant transmission may be used to communicate with both the client device 110 and the application server 130 to provide information directly to the client device 110 while deciding whether to provide notifications.

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

To achieve this goal, there are several different ways in which the sensor 120 should be constructed, and in part this construction will depend on the construction of the drug device 160 itself. In general, all sensors 120 include the network adapter described above, which functions together to record and store onboard processors, persistent memory, and drug event information and report to client device 110 and / or server 130. become. The sensor 120 may include a clock for recording the time and date of the event.

With respect to the particular sensor 120 construction, traditional inhalers, such as mechanical dose counters, were not designed with the sensor 120 in mind, so the sensor 120 may be constructed accordingly. Some implementations thus include mechanical sensors, electrical sensors, or optical sensors for detecting device 160 movement, device priming, device activation, user inhalation, and the like. In contrast, modern inhalers, such as deflectable membrane dose counters, include electrical circuits that can report event information as electrical data signals designed to be received and interpreted by sensor 120. For example, the drug device 160 itself can report movement, priming, and activation to sensor 120.

More information about the hardware and software components for the sensor 120 and drug device 160, as well as their interaction to record rescue drug events, both in their entirety are incorporated herein by reference. It can be found in US Patent Application No. 12 / 348,424, filed January 1, 2009, and International Application No. PCT / US2014 / 039014, filed May 21, 2014.

IC application server The application server 130 is a computer or a network of computers. A simplified example is shown in Figure 2, but in general, application servers have more powerful processors, larger memory, and faster speeds compared to common computing systems used, such as the client device 110. Become a server-class system that uses various network components. Servers typically use an independent content delivery network (CDN) that uses a RAID (redundant array of independent disks) array and / or contracts to store, exchange, and transmit data such as asthma notifications intended above. It has a large capacity secondary storage device by establishing a relationship with. In addition, computing systems include operating systems such as UNIX® operating systems, LINUX operating systems, or WINDOWS® operating systems. 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 / output, and peripheral device management. The operating system provides various functions for managing files stored on the device, such as creating new files, moving or copying files, and transferring files to remote systems.

The application server 130 provides a software architecture to support access to and use of the asthma analysis system 100 at a high level that can be characterized as a cloud-based system in general by many different client devices 110 through the network 150. Including. Application server 130 generally reports data recorded by patients 111 and healthcare providers 112 by sensors associated with their drug device 160, including both rescue drug events and long-term management drug events, in an asthma treatment plan. It provides a platform for collaborating, browsing and retrieving information about its state and geographic location, and using various other features.

In general, the application server 130 is designed to process a wide variety of data. The application server 130 checks the validity of incoming data, parses and formats the data as necessary, passes the processed data for storage to the database server 140, and confirms that the database server 140 has been updated. Includes logical routines that perform various functions, including.

The application server 130 stores and manages data at least for each patient. To this end, application server 130 creates a patient profile for each user. A patient profile is a set of data that characterizes patient 111 in the asthma analysis system 100. Patient profiles include age, gender, current rescue medications, current long-term medications, notification preferences, long-term management medication adherence plans, patient-related medical history, and a list of non-patient users who have been granted access to the patient profile. May include identifying information about the patient. The profile is a device, such as a unique media access control (MAC) address that identifies one or more client devices 110 or sensors 120 that are allowed to submit data about the patient (long-term management drug events and rescue drug events). Further identifiers can be specified.

The profile may specify which different types of notifications are provided to patient 111 and its dedicated healthcare provider 112, and how often the notifications are provided. For example, patient 111 may allow healthcare provider 112 to receive notifications indicating rescue events. Patient 111 may also allow access to its patient profile and rescue event history to be provided to its healthcare provider 112. If access to the patient profile of patient 111 is provided to healthcare provider 112, healthcare provider may specify a long-term management drug adherence or rescue drug plan. The dosing regimen may include a daily prescription dose for long-term management medications.

The application server 130 also creates a profile for the healthcare provider 112. The healthcare provider profile may include identifying information about the healthcare provider 112, such as the location, qualifications, and license of the clinic. The healthcare provider profile also contains information about the patient population. A donor profile may include access to the profile of the donor's patient and all of the files derived from those profiles, such as aggregate demographic information, rescue and long-term medication event patterns. This data can be further subdivided according to any type of data stored in the patient profile, such as by geographic area (eg neighborhood, city) over time (eg weekly, monthly, yearly).

The application server 130 receives rescue drug event information that triggers various routines on the application server 130 from the client device 110 or the sensor 120. In the exemplary implementation described below, the data analysis module 131 performs routines to access asthma event data, as well as other data, including patient profiles, analyze that data, and the results of that analysis. Is output to both patient 111 and donor 112. This process is commonly referred to as asthma risk analysis. Asthma risk analysis may be performed at any time in response to rescue events due to related changes in the patient's environment and in response to one of several triggering conditions discussed further below.

Other analyzes are possible. For example, risk analysis is a space for drug use based on individual, geographical, clinical, epidemiological, demographic, or spatial or temporal baselines or past significant substitutions from predicted or expected values. / Can be performed for rescue and long-term management drug use for multiple patients to identify based on temporal clusters (or sudden outbreaks). Other types of analysis include daily / weekly adherence trends, changes in adherence over time, and other relevant populations (eg, all patients, patients receiving specific rescue or long-term management medications or combinations thereof). ), Identifiers of triggers (spatial, temporal, environmental), rescue usage trends over time, and rescue usage comparisons to other related populations.

Depending on any analysis performed, application server 130 sends push notifications to send to patient 111, authorized healthcare provider 112, and / or other users who have been provided access to the patient's profile. Prepare and deliver. Notifications may provide details about the timing, location, and affected patient 111 involved in a drug rescue event. The notification may additionally include a distress or emergency signal requesting emergency assistance distributed to the emergency assistance provider 112. The notification may include the results of an asthma risk analysis performed by the data analysis module 131. More information about the types of notifications that can be sent and the content they can contain is described further below.

In addition to providing push notifications in response to asthma risk analysis, notifications may be provided as pull notifications at specific time intervals. In addition, instead of responding to asthma risk analysis performed in response to rescue drug events, instead to change one of the fundamental factors in asthma risk analysis to ensure updated notifications. Depending on the risk analysis performed in response, several notifications (whether push or pull) can be triggered. For example, if weather conditions indicate that increased air pollution is occurring or imminent, this is an asthma risk analysis for all patients located within a particular geographic area of pollution. Can trigger the execution of.

Notifications are a data format specifically designed for use with client applications and are provided to client applications 115 over network 150, with additional or alternative short message service (SMS) messages, emails, and phone calls. , Or may be provided as another data format communicated using other communication media.

ID database server The database server 140 stores data related to patient data and provider data, such as profiles, drug events, and patient medical history (eg, electronic medical records). Patient and provider data must be encrypted for security, at least password protected, or otherwise meet all Health Insurance Portability and Accountability Act (HIPAA) requirements. Protected by. Any analysis provided to the user (eg, asthma risk analysis) that incorporates data from multiple patients (eg, aggregates rescue drug event data) is personal to protect patient privacy. The identification is released so that the identification information is removed.

Database server 140 also stores non-patient data used in asthma risk analysis. This data includes area data for several geographic areas, such as public spaces in residential or commercial zones where patients are physically located and may be exposed to contaminants. This data can specifically include or be processed to obtain the patient's proximity to a green space (an area where many trees and plants are concentrated). Examples of region data include georeferenced meteorological data such as temperature, wind patterns, humidity, and air quality index. Another example is georeference pollution data, including particle counts for various pollutants, measured in time instances or experimentally. Area data includes information about current weather conditions regarding the time and location of rescue events, such as temperature, humidity, and air quality index. All of the above data items may change over time, so the data itself can be indexed by the hour, for example, by the hour (including minutes or hours), or by the day, Separate data points may be available over a longer period of time, such as weekly, monthly, or seasonal. The database server 140 is shown in FIG. 1 as a separate entity from the application server 130, but the database server 140, or the database server 140, is implemented as one or more persistent storage devices in the database. Just as the software application layer for interfacing with the data stored in is part of the software application layer of the other server 130, it may be a hardware component that is part of another server, such as server 130.

Database server 140 stores data according to the defined database schema. In general, data storage schemas across different data sources can vary considerably even when storing the same type of data, including cloud application event logs and log metrics, due to implementation differences in the baseline database structure. The database server 140 can also store different types of data, such as structured, unstructured, or semi-structured data. The data in the database server 140 can 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 is a query language for specifying instructions to read information from or write to the database server 140 (for example, for relational databases). Provide support for database queries in SQL, JSON NoSQL databases, etc.

With respect to the description of FIGS. 6A-6D below, the contents of the database described with respect to these figures may be stored in a database that is physically close to the application server 130 and isolated from the database server 140, as shown. .. Alternatively, those databases may be part of database server 140, as opposed to the description in FIGS. 6A-6D, which they indicate as being within the data analysis module 131. This variant and other variants thereof are within the scope of this specification.

IE network Network 150 represents various wired and wireless communication paths between the client device 110, the sensor 120, the application server 130, and the database server 140. Network 150 uses standard Internet communication technology and / or protocols. Thus, the network 150 may include links that use technologies such as Ethernet, IEEE 802.11, integrated services digital network (ISDN), and automated teller machine (ATM). Similarly, networking protocols used on Network 150 include Outgoing Control Protocol / Internet Protocol (TCP / IP), Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), etc. May include. Data exchanged over network 150 may be represented using techniques and / or formats including hypertext markup language (HTML), extended markup language (XML), and the like. In addition, all or some links can be encrypted using traditional cryptographic techniques such as Secure Socket Layer (SSL), Secure HTTP (HTTPS) and / or Virtual Private Network (VPN). In another embodiment, the entity may use custom and / or dedicated data communication technology in lieu of or in addition to the data communication technology described above.

II. Illustrative Computing Device Figure 2 is one exemplary computer 200 from FIG. 1, which can be used as part of the client device 110, application server 130, and / or database server 140, according to one embodiment. It is a high-level block diagram which shows the physical component of. Shown is a chipset 210 coupled to at least one processor 205. Coupled to the chipset 210 are a volatile memory 215, a network adapter 220, an input / output (I / O) device 225, a storage device 230 representing non-volatile memory, and a display 235. In one embodiment, the functionality of the chipset 210 is provided by the memory controller 211 and the I / O controller 212. In another embodiment, the memory 215 is coupled directly 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 memory device.

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

As is known in the art, the computer 200 may have components that differ from and / or other components shown in FIG. In addition, the computer 200 may be missing some of the components shown. In one embodiment, the computer 200 acting as the server 140 may lack the dedicated I / O device 225 and / or the display 235. Moreover, the storage device 230 may be local and / or remote from computer 200 (such as implemented within a storage area network (SAN)), and in one embodiment the storage device 230 may be. , Not a CD-ROM device or DVD device.

In general, the very physical components used in client device 110 will differ in size, power requirements, and performance from the size, power requirements, and performance used in application server 130 and database server 140. .. For example, a client device 110, which often becomes a home computer, tablet computer, laptop computer, or smartphone, will include a relatively small storage capacity and processing power, but will include an input device and a display. These components are suitable for user input of data and for receiving, displaying, and interacting with notifications provided by application server 130. In contrast, the application server 130 may include many physically separate, locally networked computers, each of which is a significant amount for performing the asthma risk analysis presented above. Has processing power. In one embodiment, the processing power of the application server 130 provided by a service such as Amazon Web Services ™. Again, in contrast, the database server 140 may include many physically separate computers, each of which has a significant amount of persistent storage capacity for storing data associated with the application server.

As is known in the art, the computer 200 is adapted to run computer program modules to provide the functionality described herein. Modules can be implemented in hardware, firmware, and / or software. In one embodiment, the program module is stored on storage device 230, loaded into memory 215, and executed by processor 205.

III. Dashboard A dashboard, for example the dashboard 300 shown in Figure 3A, allows the user to interact with the asthma analysis system 100. The dashboard 300 provides a means for transferring information on a user-to-user basis (eg, from patient 111 to provider 112) or on a user-to-system / system-to-user basis. The Dashboard 300 is accessed through Client Application 115 on Client Device 110, allowing both patients and healthcare providers to monitor drug rescue events, exchange personalized patient medical information, and asthma rescue event risk notifications. Provide a mechanism for receiving notifications such as. Patients can communicate with other healthcare providers and other patients through Dashboard 300 to discuss and share information about, for example, asthma, drug use, or asthma management. The ability to share asthma healthcare information can provide a way for patients or healthcare providers experiencing similar problems to share their personal perspectives.

Dashboard 300 allows authorized healthcare providers 112 to view, annotate, interact with, and export information about asthma patients as well as community data and statistics within various demographic or geographic segments. It also allows access to the list of. Using Dashboard 300, healthcare providers can monitor patients individually or as a whole and receive and provide feedback on how their relevant patient population responds to asthma management guidance. it can. Healthcare providers with access to individual or multiple patients establish notification thresholds, set parameters for notification, and when a patient's event history matches certain conditions (eg, rescue events). Has the ability to receive notifications. In addition, the dashboard 300 can receive and display periodic reports of event patterns for specific demographics generated by the asthma analysis system 100.

The dashboard 300 presents various information to the user through the display "card" 310, including tabular data, graphical visualization, and analysis. The display card 310 contains "bit size" information that mimics the simple organizational style found in baseball cards, which is effortlessly suitable for portable client devices 110, such as small displays common to mobile phones or tablets. The dashboard 300 may also include a system menu 305 that allows the user to navigate different categories of medical information.

The notification provided by application server 130 relates to display card 310. In general, the notification includes not only the information that will be presented to the user through application 115, but also a parameter to specify which display card 310 will be used to display the content of the notification. .. Any information pushed / pulled from the application server 130 can be associated with one or more cards. For example, notifications can be pushed to patients based on the results of asthma risk analysis. The dashboard 300 will process the notification and determine which one or more cards should be used to present the information within the notification. Continuing with this example, the recipient of the notification may request a pull of data from the application server 130. The application server 130 provides the requested data in another notification, and the dashboard 300 then determines on which display card 310 the requested information is displayed.

To interact with the presented information, some display cards 310a include an input response 315 area. For example, within the display card 310b shown in Figure 3B, the patient scrolls up and down within the input response 315 area to select a long-term management drug used to manage asthma, or an additional display card 310. You can select "Next" to go to.

The dashboard 300 can provide a variety of different display cards 310 that can be organized into categories. The information card type includes a card that displays data. The information card may display, for example, a map containing drug rescue events, statistics, and both patient and community data. Information cards are further subdivided into event display cards, trend display cards, educational display cards, and warning display cards.

The event card contains data about rescue drug events, such as a list of past drug rescue events for a particular patient, or patient rescue event data overlaid on a geographic map for a particular provider.

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

Another event card provides one exemplary drug usage report, including a map of the location of the rescue utilization event, environmental conditions at that location, and an input response area 315 for the recipient to add a trigger for the rescue utilization event. Can be displayed. Another event trend card may display rescue device usage for the previous week, including total usage over time and daily usage.

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, time trends, day of the week trends, and trigger trends for different time periods.

The education card contains information intended to educate the recipient. Education cards provide general illness information and tips for patients to reduce their risk of rescue events. Some educational cards are entered to allow recipients to specify whether the information provided is relevant or beneficial to their use in making future cards useful. Response 315 may be required.

The warning card informs the user of important information that informs the recipient that the recipient is at risk of an event and / or that no data has been received from the device over a recent period of time. Other warnings include warnings that settings on the client device are preventing data synchronization (for example, Bluetooth® is turned off), or that the patient's asthma risk score has changed. obtain.

The survey card type asks for a user response by presenting yes / no, multiple choices, or a free-form question for the user to respond. For example, a healthcare provider or asthma analysis system 100 can send a survey card with an asthma-related questionnaire to patient 111 to determine the level of disease control for a particular patient. In addition, the study card may require the type of long-term management drug that patient 111 uses to treat asthma symptoms. In general, survey cards provide application server 130 with data that may be missing in the patient's medical history or patient profile (as introduced above) and / or provide updates to potentially outdated information. To do. One or more survey cards can be used to complete the patient enrollment process and create patient profiles for storage within database server 140. For example, when patient 111 first registers with the asthma analysis system 100, application server 130 will trigger a push notification urging patient 111 to create a patient profile.

Examples of survey cards include survey questions asking if a patient has visited one of the emergency rooms as a result of an asthma rescue event, information about the patient's long-term care medication, and the patient's rescue medication to control the event. It may include how many times you have used the drug and what your daily schedule for that long-term medication is. The survey card can also ask about the patient's asthma trigger, such as whether pollen is the trigger. Some survey cards, like assessing their overall quality of life on a 5-point Likert scale, assessing their sleep quality, assessing their ability to be active in the last 7 days, etc. Can be asked. Other survey cards ask if the patient feels better or worse than yesterday, if the patient had to go to the emergency room or hospital during the last 12 months for a rescue event, and so on.

In some cases, patient behavior or sensor-reported event information that is inconsistent with existing patient information can trigger the transmission of survey cards to resolve ambiguities about the patient's situation. For example, if a patient is experiencing an asthma event that exceeds the expected count, the study card is the type that the patient is currently enumerating on that drug device 160 to verify that the correct drug is being used. You can request information about your drug. Another example shows that the information reported on long-term management drug use indicates that the patient uses the long-term management drug only once a day, but the adherence plan is that the patient uses the long-term management drug twice a day. If indicating that a long-term management drug is to be taken, System 100 may include sending a notification asking if the patient needs to change his adherence plan.

In some cases, patient behavior or sensor-reported event information that is inconsistent with existing patient information can trigger the transmission of survey cards to resolve ambiguities about the patient's situation. For example, if a patient is experiencing an asthma event that exceeds the expected count, the study card will use the drug currently listed on the drug device 160 by the patient to verify that the correct drug is being used. You can ask for information about the type of. As another example, the information reported on long-term management drug use indicates that the patient uses the long-term management drug only once a day, but the adherence plan is that the patient uses the long-term management drug twice a day. If indicating that a long-term management drug is to be taken, System 100 may send a notification asking if the patient needs to change his adherence plan.

A navigation card represents actionable data or messages that can redirect the user to another screen or card that is part of the dashboard 300 during user interaction. For example, if a patient wishes to share specific information about a long-term management drug with a physician or request a specific drug plan for a long-term management drug from the physician, enroll in the information or long-term management drug adherence plan. Navigation cards will be used to encourage sharing of. In addition, the navigation card allows the user to update information about drug rescue events.

The adherence card is designed to encourage patients to continue to use the long-term management drug on time for different time periods. Adherence cards can perform better overall, even if they are not streak or continuous execution of long-term management drug events on time. In addition, survey cards may inquire about the patient's physical condition, depending on the recording of a significant number of rescue events within each other's threshold time period. A long-term management drug event occurs when patient 111 takes or does not take the long-term management drug on time, as prescribed by the healthcare provider 112, within various periods of the day. It may be represented as a graph to show. The card may detail the daily schedule for long-term management medications and indicators to indicate whether the scheduled dose is being taken. For example, a red "X" may indicate that a scheduled dose is not being taken, and a green checkmark or a different symbol may indicate that a scheduled dose is being taken. Good.

The setup card guides the recipient in associating the sensor with the client device 110. The setup card guides the sensor to pair with the client device 110 using Bluetooth, prompts the recipient to start the pairing process, or selects the sensor device for pairing. You can urge the user or notify the user that the sensor is paired.

In some embodiments, the dashboard may present a user interface. The user interface may show a list of rescue events depending on the user's choice of "browsing timeline" input response area 315c. The list shows rescue utilization events over time and includes details such as date, time, number of puffs, and location. Recipients can edit the rescue utilization event and / or add additional details by selecting the edit dialogue response area. Some interfaces may provide the user with an event summary for the rescue utilization event. The event summary may be presented to the user depending on the user's choice of edit dialogue response area in the user interface. From the dashboard, users can also view and edit drug lists, detailed information such as drug types (rescue, long-term management drugs, etc.), medication schedules, and sensors.

IV. Event-Driven Asthma Risk Notification Figure 4 shows a dialogue diagram for providing asthma risk notification based on drug device monitoring according to one embodiment. As a first step, the patient interfaces with the dashboard 300 to initiate a patient profile (405). When the patient completes the patient profile, the client device 110 sends the patient profile for use by the application server 130 and stored by the database server 140. When the patient profile of the patient is initiated (405), the application server 130 can initiate reception of the rescue drug event detected by the sensor 120 associated with the patient's drug device 160. The initialization and completion of the patient profile is performed only once during the first use of the drug device by the patient.

When the sensor detects a rescue utilization event (410), the patient device 111 collects the rescue event data and sends it to the application server 130, which stores the event information (415). Although only one such case is shown in Figure 4, this detection and memory process is generally performed at some frequency for many patients when a rescue utilization event is detected. However, this frequency can differ from the frequency at which risk analysis is performed.

Then, referring to FIG. 5, application server 130 generally receives a rescue event whenever the patient uses its rescue drug dispenser 160 to relieve asthma-related event symptoms. At the onset of symptoms, as an example of the process for capturing such an event for a particular device 160 / sensor 120 combination, the sensor 120 may detect whether the drug dispenser 160 cover is open (505). When the drug dispenser cover is open, the sensor 120 may detect the acceleration associated with the priming of the dispenser 160 (510). For some types of drug dispensers, "priming" involves activating the mechanism for releasing the dose of drug from the packaging. In other types of drug dispensers, "priming" involves shaking the drug canister vigorously.

After the priming activity is detected, the sensor 120 is configured to store data related to the rescue event in the active memory of the sensor 120 (515). Rescue event data includes information describing the time and date associated with the rescue event, the status and status of the drug device 160 (eg, battery level), residual dose of the drug (before and after the event), self-test results, and sensor 120. May include physiological data of patients being treated with the drug device 160 as measured by. As soon as the sensor establishes a network connection with the client device 110 or network 150, the sensor sends any locally stored rescue event data to the client device 110 or application server 130 (525). If event data is first sent to client device 110, client device 110 then sends rescue event data to application server 130 as soon as client device 110 establishes a network connection with network 150 (530). .. Depending on the implementation, either the client device 110 or the sensor 120 will add the geographic location where the event occurred to the event data sent to the application server 130.

Next, returning to FIG. 4, the event data is collected and stored (415) as soon as the rescue usage event is detected (410). As soon as the rescue utilization event data is received and stored (415), the application server 130 may request further information from the patient to describe the rescue utilization event. To retrieve the information, the application server 130 generates a push notification, including a question that will be sent to the patient's client device 110 and will be queried. The client device 110 may present push communication as a survey type card 310. The patient can respond to the request by providing input 315 in response to the survey card 310. Alternatively, patient 111 may choose not to respond to the request. This is acceptable and any gaps in the information may be captured by later push notifications or upon entry by provider 112 after an interview with patient 111. In one implementation, the inability to receive additional requested data on demand does not preclude the rest of the analysis described in steps 425-445.

Information collected as part of an event or otherwise may include information about parameters that may have influenced the triggering of the event, the location of the rescue event, and markings about that location (eg, work, home, or school). In addition to the grade that represents the personal importance of the position to the patient, and any other relevant information, whether its use was preemptive (eg, the drug was taken prior to gymnastics). Can be identified (420).

In addition to requesting additional event data, application server 130 accesses context data stored from database server 140 (425). In general, contextual data refers to data other than event data, which is detected directly by the drug device at the time of atmospheric conditions, weather conditions, patient data recorded from past rescue utilization events, and rescue utilization events. It includes, but is not limited to, some other considerations that are not. In contrast, event data refers to any parameter related to the rescue event and reported by the drug device, such as drug dose, event time, event location, and associated adherence data. Both forms of data may include temporally up-to-date information as well as stored historical data. Therefore, as part of retrieving contextual data, application server 130 also accesses past rescue usage event data for patient 111. Historical data may include all past long-term management drug event data or rescue drug event data from the patient's history across various time windows of any past, and each past event will be collected during subsequent follow-up. It may include all of the same items as the (410) information reported for this event, along with any data provided.

However, in the following description, contextual data 635 and historical data 620 may be represented separately, as in FIGS. 6A and 6B. Contextual data 635 refers to geographic and area information related to the current event or the current location of the patient's client device 110, while historical data 620 is from previous rescue utilization events from the same or different patients. Refers to geographic information, area information, or event information.

IV.A. Overview of Asthma Prediction Model Figure 6A is a block diagram showing the logical components that perform the functions of the data analysis module 131 according to one embodiment. The asthma analysis system 100 provides a data analysis module 131 that analyzes the various data collected by the system, introduced above and further discussed below, to perform risk analysis on the patient when a trigger condition occurs (430). Included on 130. These risk analyses were used to generate notifications specifically configured to be sent to the patient in a timely manner to preferably avoid the occurrence of asthma events that would force the use of the rescue inhaler. To.

To perform a risk analysis, a model 640, such as a mathematical function or other more complex logical structure, is pre-stored and used as part of the risk analysis in the past to determine a set of parameter values. Trained using event data and historical contextual data. Training is discussed below with reference to Figure 6B in Section IV.B. The parameter value 630 describes a "weight" (or a critical value or other similar quantity, depending on the modeling technique used) associated with at least one of the input values. The input value refers to the numerical value or category value of the parameter of the model 640, where the input value can vary from patient to patient over time.

Risk analysis by briefly inputting the user's rescue inhaler utilization events 605, 620 aspects, and other contextual data 635, 620 into the input and parameter values 630 for the model 640 function and determining the numerical risk score. Is executed. In general, the contextual data collected for use as input values can be automatically collected based on the device or other third party data reports, or can be manually provided by the patient and / or provider. Or otherwise it can be obtained. The risk score is a numerical value generated by model 640 that characterizes the likelihood that a patient will experience an asthma rescue utilization event, taking into account event data 605 and context data 635. The risk score may then be used to specify a risk classification for the user, which is then specific to its current context, and either or both of them may be provided to the notification module 645.

Risk analysis can be triggered by trigger conditions, which can themselves be automatically scheduled, manually set, and / or occur in response to specific event or contextual information. Examples of trigger conditions include, but are not limited to, changing input values, the consequences of a rescue event, or the termination of a time interval.

As part of the Model 640 training process, during model use, Module 131 generally generates a baseline for the patient on a periodic basis, where the baseline is used in other functions of the risk notification process. To do this, event data 605 is received by the baseline generation module 610 and used to generate the baseline, which is then stored in the baseline database 615 for later use. This process of generating a baseline generally occurs at a specified frequency, regardless of the occurrence of an event or trigger condition that can trigger system activity in some cases. The methodology for generating the baseline will be further described below with reference to FIGS. 6C-6D.

IV.B. Model Training For model training and Figures 6B and 6C, the model is trained against the labeled historical data, where past events and past contextual data related to the previous day are It is associated with the indicated indication of whether the day was associated with high risk or low risk. This decision on high-risk or low-risk marking is based on whether the events associated with that day exceed the baseline threshold for that day.

FIG. 6B is a block diagram showing a logical architecture for training a model according to one embodiment. To create the dataset used to train the model, the accessed historical data is aggregated / segmented daily to identify input values for various parameters. In general, one day's worth of information is associated with one training sample. Atmospheric and meteorological data can be obtained from historical datasets from the US National Oceanic and Atmospheric Administration (NOAA) and the Environmental Protection Agency (EPA).

Baseline thresholds are established daily to create markings for each training sample, and model 640 determines whether the daily baseline threshold is exceeded based on the number of rescue utilization events for that data. decide. A complete description of determining baseline thresholds is discussed below in Section IV.D with respect to Figure 6D, but in general, the markings associated with a given training sample were considered "high risk" for the day. Or represents the determination of what was considered "low risk".

FIG. 6C is a diagram showing a method for training a model using the training dataset 650 according to one embodiment. The relationship between the input values of training samples 650 (table cells, represented by A) (each row of the table) and the labels (C) of these samples is best represented (for example, for each parameter not shown). Model 640 is trained by determining the (associated) parameter values. As introduced above, model 640 is trained using function (B) or another more complex logical structure. In one embodiment, the model 640 is trained using machine learning techniques, examples of machine learning techniques include linear regression, logistic regression, and other forms of regression (eg, elastic net), determination. Includes, but is not limited to, trees (eg, random forest, gradient boosting), support vector machines, classifiers (eg, naive bays classifiers), and fuzzy matching. An exemplary model 640 trained with gradient boosting is described in Section IV.E below.

Once the parameter values are known, the model 640 is used, as discussed in Figure 6B, by accessing the parameter values and the function specified by the model and entering the input values for the parameters to generate a risk score. obtain.

IV.C. Input Parameters The parameters incorporated within the risk score analysis can be divided into several groups: past patient parameters, current patient parameters, air pollutant parameters, and meteorological parameters. Past and present patient parameters can be broadly categorized simply as "patient parameters". Air pollution and meteorological variables can be broadly categorized simply as "environmental condition parameters". The numerical value of the parameter is included in the function generated in the form of the input value, as described above. Furthermore, the parameter values of the model are derived from the parameters.

Past patient characteristics are the cumulative patient history of rescue events over a period of time (pr_7_rscu_sum), the cumulative count of days the rescue unit is used (norm_day), the disease type (disease_asthma), and the rescue events that occur at night. Records, and long-term management drug adherence records (pr_sun_adh) may be included, but not limited to. The patient history of the rescue event may include any relevant information related to the categories mentioned above for any previous rescue event. The disease type describes the severity of the patient's asthma, as well as personal treatment. The long-term management drug adherence record contains information about the patient's use of that long-term management drug (which can also be associated with sensor unit 160). This decision is evaluated by observing examples where the use was prescribed but not performed, when the use was prescribed and performed, and when the use was not prescribed and performed.

Current patient characteristics may include, but are not limited to, the current latitude (lat), longitude (lon), and coordinate location of client device 110, as well as the current date (month, day_of_week). The current latitude and longitude are used to determine the geographic location of the patient from which information about the patient's environmental conditions can be determined. The current rescue event data also shows the difference between the number of rescue puffs taken and the number prescribed, as well as a count of all rescue events that may have already occurred on that day and information related to those events. Can include.

Air pollutant characteristics can include information about concentrations (eg, analog values), or more binary indications of the presence or absence of pollutants. Examples of pollutants considered are ozone molecules (O ₃ ), nitrogen dioxide molecules (NO ₂ ), sulfur dioxide molecules (SO ₂ ), particulate matter of size 2.5 micrometers or less (PM _2.5 ), size 1.0 micrometers or less. Including, but not limited to, Particulate Matter (PM _1.0 ), and Air Quality Index. Specific meteorological features may include temperature (drybulbfahrenheit), humidity (relative humidity), wind speed (windspeed), wind direction (wind_direction_cat), local air pressure (station pressure), and visibility.

IV.D. Threshold Determination As introduced above, baseline risk thresholds are used in both model training and risk score calculations. The baseline generation module 610 spans the specified previous time period preceding the day on which the risk is calculated (either during training or during model use), or more generally. The baseline risk threshold is calculated based on the total number of utilization events during the time period preceding the time of the current / recent rescue utilization event.

In one example, the time period is exclusively limited to the current day and the previous 7 days (thus, the data for the day is excluded), but other time periods may be used. .. For example, if there is no cumulative data for 7 days due to the recent creation of a patient profile or because utilization events have not been tracked during this time window, the baseline will instead utilize the data. It can be calculated based on the number of possible days.

In one embodiment, the baseline risk threshold is set as a percentage of the total number of usage events over a specified time period, whereas in other embodiments, usage events are used to determine the threshold. Other ratios of the total number of may be used.

FIG. 6D shows two exemplary risk threshold determinations, and their use in determining markings for training samples in a training dataset, according to one embodiment. First, the total number of usage events from the previous 7 days is added and recorded. For both examples, this total is 30 events. Second, the risk threshold is determined as the number of events, in this case 1.5 events, equal to 5% of the total.

In training, samples (events and other data about daily events) are labeled as "1" or "0", where 1 indicates high risk to the patient and 0 indicates low risk. Since this is historical data, this "assignment" of risk caused the behavior to occur as the patient's condition worsened, based on the presumption that more rescue-using inhaler events had occurred for the user. It suggests that some complex combination of parameter inputs will be worse than on other days. Therefore, in a marking scenario, it is not as inherent a risk as the occurrence that the model is trying to identify to avoid in the future.

To assign a sign, if the number of rescue inhaler utilization events on a given day exceeds the threshold, 1 is assigned here if it exceeds 5% of the 30 events aggregated over the last 7 days. Be done. Otherwise, 0 is assigned. Figure 6D shows possible examples of both when the sensor 160 reports an event twice a day and when an event is reported once a day. These final decisions allow the model to determine, when trained, what combination of input values, what kind of event constitutes a risk event, and what kind does not. In contrast to a fixed number of events, setting thresholds based on some of the events in the previous period provides greater flexibility and variability in adjusting the thresholds to the patient's particular disease state. To enable. Specifically, if the patient's rescue inhaler utilization has increased over the course of several days, making the threshold dynamic in this way does (or does not) a parameter worsen the patient's condition. Allows better identification of whether or not. In one embodiment, the baseline risk threshold reveals a tailed usage pattern with a frequent zero asymmetric distribution, above the median day, but on average for 7 days. Set to 5% instead of some higher threshold, such as 14% (representing the daily average from a 7-day history) to ensure a high-risk classification for days with usage events below ..

IV.E. Example of Gradient Boosted Decision Tree In one embodiment, model 640 is a gradient boosting model. In general, gradient boosting requires the use of weak predictive models, generally decision tree ensembles. In the case of decision trees, each tree is a relatively shallow, weak learner that deals with only a few parameters. The training mechanism of model 640 is an iterative functional gradient descent algorithm. That is, this algorithm optimizes the cost function in the parameter space by iteratively selecting a function pointing in the negative gradient direction (weak hypothesis). In other words, at each iteration of training, the algorithm parameters for the new tree so as to minimize the errors identified by the cost function from those trees and the parameter values of the previous iteration. To select.

In one particular embodiment, the XGBoost set of algorithms and frameworks is used as the baseline for Model 640. One exemplary model is max_depth = 9, min_child_weight = 1, gamma = 0, learning_rate = 0.1, n_estimators = 1000, subsample = 0.8, colsample_bytree = 0.8, objective = binary: logistic, nthread = 4, scale_pos_weight, and seed. It was executed using the variables in the XGBoost set so that = 27. More details on the XGBoost algorithm can be found at http://xgboost.readthedocs.io/en/latest/python/python_api.html. Cross-validation was performed on the data. For convenience of the rest of the discussion, this example is called the XGBoost Example Model.

IV.F. Using Asthma Prediction Model Next, returning to Figure 4, application server 130 uses the trained model to perform asthma risk analysis 430 and the patient experiences an asthma event in the near future. Determine the risk of becoming. This risk is performed as a numerical score, but may be processed into risk classifications, such as whether the patient is in a high risk category, a medium risk category, or a low risk category. .. This information can be used, in particular, to attempt to influence changes in patient behavior to avoid predicted events.

Then referring to Figure 6A, the data analysis module 131 accesses the input value so that the model can be used, where the input value is one of the current rescue event data 605, past. Determined from rescue event data 605, current context data 635, past context data 635, and parameter value 630. Module 131 also determines or accesses the baseline risk threshold, depending on whether a sufficiently up-to-date threshold exists in database 615. Model 640 uses these inputs to determine the risk score. As discussed above, model 640 is trained on a normalized risk value of 1 or 0, which indicates whether a particular day before was a high "risk" for the patient. The numerical risk score generated by model 640 will also be comprehensively normalized between 0 and 1. Therefore, the numerical risk score represents the model 640's determination as to whether the current input value indicates that the patient is at high risk or at low risk. In addition, the 1/0 marking is not based on whether the patient originally used the rescue inhaler, but based on whether the patient exceeded the dynamic threshold, which in some cases was the patient's previous time period. Recall that it is set based on whether the moving window average is slightly exceeded over time. Therefore, similarly, the risk score output by the model is not only whether the rescue inhaler utilization event will occur, but also whether the rescue utilization event will occur, or instead, the patient is currently Reflects whether it is based on an input value that is expected to exceed its own moving window average identified by the baseline risk threshold of.

Module 131 may further classify the risk score as high risk, medium risk, or low risk, or any other classification that applies the risk score to the context. As an example, scores considered low risk range from 0.0 to 0.1, medium risk ranges from 0.1 to 0.8, and high risk ranges from 0.8 to 1.0.

IV.G. Asthma Rescue Event Risk Notification Notification Module 645 is among the classification, risk score, potential causes of risk score, and options that patients may have to prevent the occurrence of another rescue event under these circumstances. Generate a risk score notification that includes one or more of (435). As discussed above, application server 130 generates risk score notifications for one or more of patient 111, its healthcare provider 112, and / or any other licensed individual. (435).

The risk notification may include a wide variety of information content, including a risk score, classification, and any of the input values from any of the parameters of model 640.

The risk notification can consist of recommendations on how to prevent further rescue inhaler events based on the parameters that cause the risk classification change. For example, recommendations are to follow adherence schedules more closely, increase the dose or use of long-term controlled drugs, avoid their geographic area altogether, or limit exposure to areas with similar environmental conditions. May include doing.

In addition, patient 111 may be provided with a geographic map with all pinpoints of its drug rescue event location that occurred the previous year. As another example, patient 111 is given all drug rescues that occur in a geographic area near either that day or within a threshold time period to show recent patterns of drug rescue events for that area. A geographic map containing the location of event 410 may be provided, along with pinpoints of the event. As another example, the healthcare provider 112 of patient 111 is presented with drug rescue event data from that patient 111 from that day or recent time period to help the provider 112 identify drug rescue event trends. May be done.

Risk notifications may be delivered in many other situations, depending on the implementation, which may be based on trigger conditions or may be sent to the client device according to some other mechanism. For example, changes in patient parameters (eg, the patient's reduced long-term management drug adherence tendency) or environmental condition parameters (eg, low concentrations of ozone, higher pollutants in the air, or higher humidity) cause the patient's current If the condition worsens, an updated risk notification will be delivered to patient 111. Alternatively, updated risk notifications may be delivered if the patient's current condition is ameliorated by similar changes. Risk notifications may be delivered at the patient's request, for example, by verbal request for local asthma conditions from a third party device (eg, Google Home ™ or Amazon Alexa ™).

As described above, the risk notification is generally delivered through the client device 110, but in other embodiments, if the condition improves or worsens, the risk notification will be an SMS notification, email notification, local asthma condition. It can be delivered as a notification from an embedded widget with, or from various IFTTT applets (https://ifttt.com/).

V. Example
VA Example 1
FIG. 7A characterizes the training dataset by showing the percentage of days marked as 1 and the percentage of days marked as 0. In addition, the graph shows an increase in the number of days classified as high risk based on the baseline risk threshold with the 5% factor and the baseline risk threshold without the 5% factor as discussed above. .. One day user (patient), along with Propeller Health ™ patient inhaler data for the air environment and meteorological data from past NOAA and EPA datasets from April 30, 2012 to April 30, 2017. ) Represents a data set. For users lacking location information, inconsistencies are filled with the most recently logged locations during that 24-hour period. If there are no logged locations during that 24-hour period, the data for that day will be removed from the dataset. The total dataset consisted of 5,309 users and 720,812 user-days, 15% of which were classified as high risk (ie, 1). Low risk days are classified as 0. Of the total dataset, 5,202 users and 178,920 user-days were selected for the training set. To improve model training, subsampling techniques are used to balance the training set (for example, the same number of events labeled 0 and 1). The test set consists of 3,982 users and 35,848 days of users-days, with 15% of users-days classified as high risk and remains unbalanced.

The data showed that when using the XGBoost Example Model, 98% of the days with one event were classified as high risk compared to 75% high risk days under the threshold model without%. showed that. This significant improvement in accuracy reduces the likelihood that the device will not be aware of any given high-risk rescue utilization event. In addition, the XGBoost Example Model then addresses the issue of the precisely clipped distribution of daily utilization events for individual patients discussed above.

VB Example 2
Figure 7B illustrates why the baseline risk threshold is set as a percentage of the sum of time periods prior to the rescue utilization event (for example, 5%). The previous model (referred to herein as "V1") is the optimal combination of AUC score, accurate measurements, and sensitivity and specificity indicators (before the sample set has 30,790 patient days of data). 26% of the events were classified as high risk (ie, marked as "1"), subject to (based on data from). Other similar iterations of a similar model also classified the higher 20% of patient days as high risk. This is impractical when compared to surveyed and separately identified measurements, where most patient days are at high risk. When designing a training dataset for the XGBoost Example Model, the 5% threshold better represents the traditionally determined high-risk day ratio (less than 5%, as shown in Figure 7a). I understood. Training data consisting of 5,202 users and 178,920 days of user-days was constructed to train the XGBoost Example Model. To improve model training, subsampling techniques are used to balance the training set (for example, the same number of events marked 0 and 1).

VC Example 3
Figure 7C shows the same performance criteria for the XGBoost Example Model. The training set and test dataset are the same data identified in Figure 7A. While these performance criteria suggest reduced effectiveness from V1 model measurements, the GBoost Example Model addresses defects in the V1 model. Part of the decrease in specificity may be due to significantly more low-risk days than high-risk days. Only 15% of the XGBoost Example Model test set events were at high risk compared to 85% of low risk events. In comparison, the V1 test set was simply a 78% low risk event. In addition, the XGBoost Example Model considers additional parameters in terms of its risk analysis and risk classification performance compared to the V1 model.

VD Example 4
Figure 7E shows the distribution of days from a test set classified as high risk, medium risk, and low risk by the XGBoost Example Model. 54% of the days considered low risk make up the majority of the test set, followed by 38% considered medium risk and 7% considered high risk. This risk category distribution is broadly consistent with the classification generated by the V1 model, where low-risk and medium-risk predictions far exceed high-risk predictions. Specifically, in the V1 model, low-risk predictions make up 49% of the test set, medium-risk predictions make up 32%, and high-risk predictions make up 20%.

VE Example 5
Figure 7F classifies the distribution of rescue events, which represents risk expectations based on the total number of daily rescue events, based on the test dataset for the XGBoost Example Model described above. Of the days classified as low risk, most days had 0 events, but there were rare cases where each day recorded more events. Within the medium risk category, most days have 0 events, and most days have 1-3 rescue events and 3-6 rescue events. As can be seen in the low-risk category, there were rare cases where each day recorded a higher number of events. Within the high-risk category, there were a small number of records with 0 events compared to the previous category, but 1-3, 3-6, 6-10, and 10 or more times a day. There were more records within the scope of the event. Similar to the data in Figure 7E, the predictive trends from the XGBoost Example Model followed the same general distribution as the V1 model, recording more than 6 events with more days classified as high risk.

VF Example 6
Figure 7G illustrates the risk score variance over the majority of users in the XGBoost Example Model. The same test dataset described above was used to perform the analysis. Within the test dataset, approximately 10% of patients were definitely diagnosed with COPD. All patients considered in the test set had cumulative data equivalent to 6 days or more. Only 1% of users find that 90% of daily life is classified as high risk, only 4% of users find that 90% of daily life is classified as medium risk, and only 5% of users We found that 90% of daily life is classified as low risk. By comparison, 89% of users found a fluctuating risk category that did not have a single risk category that alone represented a 90% majority. The number of patients in variable risk categories suggests that this model is very sensitive to changes in parameter values, whether the parameter values are related to contextual data or event data. This is further evidenced by a comparison to the V1 model, where 64% of users experience variable risk scores, which reveals fewer parameters and changes in contextual and event data. This is because the sensitivity to is lower.

VG Example 7
Figure 7D illustrates some parameters of the XGBoost Example Model and assigns each parameter an importance score that represents the importance of the parameter in the risk analysis decision. Determining the importance of various parameters is completed during model training to determine the parameter values that the model associates with those parameters. Therefore, the training dataset is consistent with the features described with reference to FIGS. 7A-7B. Based on model parameters and test data, the most important parameter is the historical parameter, with a score of 0.08 for the number of days the patient used Propeller Health ™. The most important context parameters are SO ₂ concentration, wind speed, temperature, PM _1.0 , PM _2.5 , NO ₂ concentration, and O ₃ concentration, all of which score 0.07, all of which are not considered by the V1 model. It was.

VH Example 8
Figure 7H describes the average number of rescue puffs over the first 7 days when a patient is monitored using the Propeller Health ™ system. The average number of rescue puffs was determined using the test dataset described above. Given the improved dataset, the plot then more closely mimics the general rescue curve of Propeller Health ™, suggesting an improvement in the XGBoost Example Model over V1. In addition, this indicates that monitoring results in significant improvements in rescue inhaler utilization within the time period of the first week, and the monitoring and harmonious notifications described herein are patient rescue inhalers. It suggests that it can help reduce usage.

VI Example 9
Figure 7I further characterizes the data from the average first 7-day training dataset, which describes the number of users considered to be at high risk on each day of the first 7 days. Overall, it represents a decrease in the proportion of high-risk users daily compared to the V1 model, suggesting an improvement in overall experience during the first week. Specifically, on day 1, 27% of users of the XGBoost Example Model test set were considered high risk compared to 35% of users of the VI model. Between days 2 and 7, respectively, compared to VI models where 37%, 38%, 31%, 31%, 30%, and 29% of users were determined to be at high risk, respectively. , XGBoost Example Model 14%, 24%, 27%, 18%, 13%, and 15% of users were classified as high risk.

VI. Benefits Asthma rescue event risk notifications provided to Patient 111 and Provider 112 bring many benefits. Patients are informed about the risk of their asthma rescue event in real-time or near-real-time (in seconds to minutes), for example, by improving adherence to their long-term treatment, adverse conditions (eg, air pollution levels). By staying away from the geographic area of possession, adding or amending its prescribed medication (such as adjusting medication or introducing antibiotics or systemic corticosteroids), or to the recent surge in rescue drug use Measures can be taken to prevent its occurrence by scheduling doctor appointments to address and reducing the frequency of emergency room and hospital visits for patients. Event data is automatically reported to application server 130 without the need for patient input, so the accuracy and quality of event data compared to data manually collected by healthcare providers 112 or other entities. Is improved, and therefore the accuracy of conclusions about the risk of asthma rescue events is also improved.

In addition, supplemental notifications provided by Application Server 130, including reporting of upcoming rescue drug events by other patients, provide patients with additional information about others suffering from similar problems and the patient's intentions. Regional information related to the decision can be provided. Supplementary notices may further encourage users to improve their adherence medication intake. Ideally, such notification would prevent the occurrence of asthma rescue events, thus preventing the patient from being harmed, as well as hospital visits and associated costs.

Informed about the risk to one or more of the patient's asthma rescue event risks, the healthcare provider should follow the patient's improvement as well and use the information to improve the treatment for each patient. It is possible to schedule appointments with patients. For patients at high risk of an asthma rescue event, the notification can be a call for measures to encourage the healthcare provider to communicate with the patient and encourage the patient to seek medical care. Supplemental notices may provide information on territorial impacts (eg, contamination), patient long-term management drug adherence, and the like.

VII. Additional considerations Although the above discussion focuses specifically on asthma, all systems and processes described herein are generally equally applicable to COPD and chronic respiratory disease (CRD). Yes, and as a result, it can also be used to support the treatment of COPD and CRD, asthma.

The drawings and description of this disclosure have been simplified to exclude many other elements found in general systems for clarity, while at the same time showing relevant elements for a clear understanding of this disclosure. Please understand that. Those skilled in the art will recognize that other elements and / or steps are desirable and / or required in the implementation of this disclosure. However, discussions of such elements and steps are described herein because such elements and steps are well known in the art and they do not facilitate a better understanding of the present disclosure. Not provided by. The disclosure herein covers all such modifications and modifications to such elements and methods known to those of skill in the art.

Some parts of the above description describe embodiments in terms of algorithms and symbolic representations of behavior for information. These algorithm descriptions and representations are commonly used by those skilled in the art of data processing techniques to effectively convey the content of their work to others skilled in the art. Although these operations are described functionally, computationally, or logically, it is understood that they can be implemented by computer programs or similar electrical circuits, microcode, and the like. Moreover, it has proved sometimes convenient to call these configurations of operation modules, without losing generality. The described operation and its associated modules may be performed in software, firmware, hardware, or any combination thereof.

References to "one embodiment" or "some embodiments" used herein indicate that the particular elements, features, structures, or properties described with respect to this embodiment are included in at least one embodiment. means. The appearance of the phrase "in one embodiment" at various points in the specification does not necessarily refer to the same embodiment.

As used herein, "comprises," "comprising," "includes," "including," "has," and "have." "Having", or any other variant thereof, is intended to cover non-exclusive inclusion. For example, a process, method, article, or device that includes a list of elements is not necessarily limited to those elements, but is explicitly listed or otherwise specific to such process, method, article, or device. Can include elements of. Further, unless otherwise stated, "or" refers to inclusive or (or) and exclusive or (or). For example, condition A or B is satisfied by one of the following: A is true (or exists), B is false (or does not exist), and A is false (or does not exist). B is true (or exists), and A and B are both true (or exist).

In addition, the use of "a" or "an" is adopted to illustrate the elements and components of embodiments herein. This is done solely for convenience and to give the general meaning of the present invention. The specification should include one or at least one, and the singular form should also be read to include the plural form unless it is clear that it means something else.

Although specific embodiments and applications have been shown and described, it should be understood that the disclosed embodiments are not limited to the very structures and components disclosed herein. Various modifications, changes, and modifications that will be apparent to those skilled in the art, without departing from the spirit and scope as defined in the appended claims, constitute the methods and devices disclosed herein, and the configurations, operations, and modifications. Can be done in detail.

100 Asthma analysis system, COPD analysis system, system
110 Client Computing Device, Client Device
111 patients
112 Healthcare providers, providers, emergency assistance providers
115 Client Software Applications, Applications, Client Applications
120 drug device sensor, sensor
130 application server, server
131 Data analysis module, module
140 database server, server
150 networks
160 Drug devices, devices, long-term management drug devices, rescue drug devices, drug dispensers, rescue drug dispensers, dispensers, sensor units
200 computers
205 processor
210 chipset
211 memory controller
212 I / O controller
215 Volatile memory, memory
220 network adapter
225 Input / O (I / O) devices
230 storage
235 display
300 dashboard
305 System menu
310 card, display card, survey type card, survey card
310a display card
310b display card
315 Input response, input
315c Input response area
410 event
430 Asthma risk analysis
605 Rescue inhaler usage event, event data, rescue event data
610 Baseline generation module
615 Baseline database, database
620 Historical data, rescue inhaler usage events, contextual data,
630 parameter value
635 contextual data,
640 model
645 Notification module
650 training dataset, training sample

In general, the very physical components used in client device 110 will differ in size, power requirements, and performance from the size, power requirements, and performance used in application server 130 and database server 140. .. For example, a client device 110, which often becomes a home computer, tablet computer, laptop computer, or smartphone, will include a relatively small storage capacity and processing power, but will include an input device and a display. These components are suitable for user input of data and for receiving, displaying, and interacting with notifications provided by application server 130. In contrast, the application server 130 may include many physically separate, locally networked computers, each of which is a significant amount for performing the asthma risk analysis presented above. Has processing power. In one embodiment, the processing power of the application server 130 is provided by a service such as Amazon Web Services ™. Again, in contrast, the database server 140 may include many physically separate computers, each of which has a significant amount of persistent storage capacity for storing data associated with the application server.

The adherence card is designed to encourage patients to continue to use the long-term management drug on time for different time periods. Ad HERE lance card may indicate a "streak (streak)" or continuous execution of the long-term management drug events of the time. In addition, survey cards may inquire about the patient's physical condition, depending on the recording of a significant number of rescue events within each other's threshold time period. A long-term management drug event occurs when patient 111 takes or does not take the long-term management drug on time, as prescribed by the healthcare provider 112, within various periods of the day. It may be represented as a graph to show. The card may detail the daily schedule for long-term management medications and indicators to indicate whether the scheduled dose is being taken. For example, a red "X" may indicate that a scheduled dose is not being taken, and a green checkmark or a different symbol may indicate that a scheduled dose is being taken. Good.

VB Example 2
Figure 7B illustrates why the baseline risk threshold is set as a percentage of the sum of time periods prior to the rescue utilization event (for example, 5%). The previous model (referred to herein as "V1") is the optimal combination of AUC score, accurate measurements, and sensitivity and specificity indicators (before the sample set has 30,790 patient days of data). 26% of the events were classified as high risk (ie, marked as "1"), subject to (based on data from). Other similar repeats of a similar model also classified ≥20 % of patient days as high risk. This is impractical when compared to surveyed and separately identified measurements, where most patient days are at high risk. When designing a training dataset for the XGBoost Example Model, the 5% threshold better represents the traditionally determined high-risk day ratio (less than 5%, as shown in Figure 7a). I understood. Training data consisting of 5,202 users and 178,920 days of user-days was constructed to train the XGBoost Example Model. To improve model training, subsampling techniques are used to balance the training set (for example, the same number of events marked 0 and 1).

Claims (25)

A step of accessing a set of past rescue inhaler utilization events for a patient, said set of events received previously from an attachment associated with a client device or rescue inhaler unit, or from said rescue inhaler unit. And the rescue inhaler unit provided the rescue drug to the patient as part of each of the events.
Steps to determine patient-specific baseline risk thresholds based on the set of events,
Depending on the trigger condition,
Steps to access a set of parameter values for a model for predicting asthma risk,
Steps to access a set of input values,
A step of inputting the parameter value, the input value, and the baseline risk threshold into a function for determining a risk score.
A method comprising sending a notification to the client device based on the risk score. The method of claim 1, further comprising receiving the past rescue inhaler utilization event from the client device, the attachment, or the rescue inhaler unit. The method of claim 1, wherein the threshold is determined with respect to a previous period, wherein the previous period comprises an event from a window of time preceding the current time. The method of claim 3, wherein the threshold is determined as a percentage of the sum of the events within the previous period. The method of claim 1, wherein the threshold is determined cyclically. The method of claim 1, wherein the trigger condition includes a threshold change in the physical position of the client device. The method of claim 1, wherein the trigger condition comprises a periodic conclusion of a time interval. The method of claim 1, wherein the trigger condition includes a threshold change of at least one of the input values among the plurality of parameters. The trigger condition includes the occurrence of a current rescue inhaler utilization event, the current event being received from the client device, the attachment, or the rescue inhaler unit, where the rescue inhaler unit is the current rescue inhaler. The method of claim 1, wherein the rescue agent was provided to the patient as part of an event. The method of claim 1, wherein the parameter values are determined using a boosted gradient model. The method of claim 1, wherein the risk score is a number representing the likelihood that the patient will exceed the threshold on that day. The method of claim 1, wherein the parameters include at least one event data parameter and at least one context data parameter. The parameters are
Cumulative patient history of rescue events,
Patient history of events that occur at night,
Cumulative count of the day using the rescue unit,
The method of claim 1, comprising at least one past patient parameter, further comprising disease type and adherence record. The parameters are
The current longitude and latitude coordinates of the client device,
Current position,
The method of claim 1, comprising at least one current patient parameter, further comprising a difference in the current date and the number of rescue puffs taken and prescribed for the rescue event. The parameters are
Ozone molecule (O ₃ ),
Nitrogen dioxide molecule (NO ₂ ),
Sulfur dioxide molecule (SO ₂ ),
Particulate matter less than 2.5 micrometers (PM _2.5 ),
Particulate matter less than 1 micrometer (PM _1.0 ), and Air Quality Index (AQI)
The method of claim 1, further comprising at least one air pollutant parameter. The parameters are
temperature,
Humidity,
wind speed,
Wind direction,
The method of claim 1, comprising at least one meteorological parameter, further including local air pressure and visibility. The parameters are
temperature,
Relative humidity,
Wind speed parameters,
Nitrogen dioxide (NO ₂ ),
Sulfur dioxide (SO ₂ ),
Particulate matter less than 2.5 micrometers (PM _2.5 ), and
Particulate matter less than 1 micrometer (PM _1.0 )
The method of claim 1, comprising. The method of claim 1, wherein the parameter comprises the number of days that a rescue inhaler utilization event is monitored by a computing system external to the rescue inhaler unit. The method of claim 1, wherein the function determines whether the number of rescue inhaler utilization events for a given day exceeds the threshold. The method of claim 1, wherein the risk notification is presented at a first time different from the second time at which the risk threshold is determined. The method of claim 1, wherein the risk notification comprises information content relating to the trigger condition. The risk notification is
Said event,
The method of claim 1, comprising information content relating to the baseline risk threshold and at least one of the risk classifications based on the risk score. The method of claim 1, wherein the risk notification further includes information content relating to the rescue event, which further includes a subset of parameters that cause a change in the risk classification compared to a previous time period. The risk notice further includes information content about the rescue event, the information content further includes recommendations on how to prevent future rescue inhaler events, and the recommendations are responsible for the change in risk classification. The method of claim 1, which is based on a subset of the parameters. A non-temporary computer-readable storage medium with computer program instructions that, when executed by a computer processor, tells the processor.
Accessing a set of past rescue inhaler utilization events for a patient, said set of events being received previously from an attachment associated with a client device or rescue inhaler unit, or from said rescue inhaler unit. The rescue inhaler unit provided and accessed the rescue drug to the patient as part of each of the events.
Determining patient-specific baseline risk thresholds based on the set of events,
Depending on the trigger condition,
Accessing a set of parameter values for a model for predicting asthma risk,
Accessing a set of input values and
Entering the parameter value, the input value, and the baseline risk threshold into a function for determining the risk score, and
A non-temporary computer-readable storage medium that causes a notification to be sent to the client device based on the risk score.