Patent Description:
Asthma remains a significant and costly public health problem. Worldwide, the World Health Organization estimates the population with asthma may be <NUM> million, and predicts that it will rise to <NUM> million by <NUM>. In the United States, asthma affects <NUM> in <NUM> individuals in the U. and prevalence is on the rise, leading to more than $<NUM> billion per year in health care utilization costs.

Despite the development of new medications, rates of hospitalizations and emergency room visits have not declined. Each year in the United States the disease causes approximately <NUM> million emergency department visits, <NUM>,<NUM> hospitalizations, and <NUM>,<NUM> deaths. In addition, asthma is responsible for an estimated <NUM> million missed days of school, and <NUM> million days of work. Total annual costs to US health insurers and employers are greater than $<NUM> billion.

The majority of these exacerbations could be prevented with currently available treatments; however, only <NUM> in <NUM> asthmatics has the disease under control. Newly revised national guidelines urge doctors to more closely monitor whether treatment is controlling everyday symptoms and improving quality of life. Physicians, however, have few available tools to assess how well their patients are doing day-today. An increasing number of physicians have begun to use periodic, written questionnaires (such as the Asthma Control Test) to monitor patients and determine their level of control. These instruments require patients to accurately recall and report the frequency of symptoms, inhaler usage, and activity level and restriction over some period of time (usually two to four weeks). As a result, these questionnaires are subject to error introduced by biases (recall), different interpretations of symptoms, and behaviors (non-adherence), and only provide information at the time they are used.

More generally, medicament devices such as inhalers dispense corticosteroids which allow patients to manage respiratory symptoms such as constricted airflow. When patients use medicament devices, the ability to accurately record instances of medication events and send recorded instances to physicians allows better monitoring of patients by physicians. A medicament device sensor attached to such medicament devices such as inhalers can aid in recording instances of medicament dispensing and transmitting the recorded instances to a server; however such events are generally reported much later than their time of occurrence, if at all. In some instances, such events are reported many hours if not days later, which is problematic. <CIT>relates to a compliance monitor for monitoring patient usage of a dry powder medicament delivery device. The medicament delivery device includes a store of medicament housed within a main body portion, and a base portion which is rotatable with respect to the main body portion. The medicament delivery device also includes a medicament dispensing means for dispensing a dose of medicament into an inhalation chamber, a mouthpiece through which the dose of medicament may be inhaled by a user, and a replaceable cap. The compliance monitor includes a first portion for receiving and/or retaining the base portion of the medicament delivery device, and a second portion for releasably securing the medicament delivery device to the first portion. <CIT> discloses a dose selective breath actuated inhaler which includes a meterless canister storing a pressurized medicament, and a vacuum actuated release, where application of a vacuum to the inhaler initiates a release of the medicament in the canister. The inhaler includes a mechanism for dialing a proper dose of pressurized medicament, a computer for generating a plurality of signals including a solenoid trigger signal, and a solenoid which upon receipt of a solenoid trigger signal actuates a solenoid arm to end the release of the medicament from the canister.

The subject-matter of the present invention is defined by the features of the independent claim. Further preferred embodiments of the present invention are defined by the features of the dependent claims. The present disclosure describes a medicament device sensor, specifically a single dose inhaler monitoring attachment. The single dose inhaler is used to provide a single medicament dose at a time through priming of the medicament dose then inhalation by a user. The monitoring attachment has many features which aim to secure the monitoring attachment to the single dose inhaler. These features include a securement clip, a body including two walls with asymmetry, and grooves corresponding to dosing buttons on the single dose inhaler. The securement clip fits over a ledge on the single dose inhaler. The body is asymmetrically shaped in at least two orthogonal planes such that there is one orientation for securing the monitoring attachment onto the single dose inhaler. The body also comprises a wall opposite that of the securement clip which provides tension on the single dose inhaler. The grooves along either side of the monitoring attachment allow for the single dose inhaler's dosing buttons to fit in the grooves. To detect whether the monitoring attachment is secured to the single dose inhaler, the monitoring attachment uses a limit switch that is depressed when the monitoring attachment is firmly secured onto the single dose inhaler. Once the monitoring attachment is secured, the monitoring attachment can activate other sensors for recording medicament usage events.

For accurately recording priming of the medicament dose and inhalation by the user, the monitoring attachment comprises two limit switches coupled to the dosing buttons and an audio sensor. The two limit switches are depressed when the two dosing buttons on the single dose inhaler are pressed. If a capsule with the medicament dose is loaded into the single dose inhaler, pressing the two dosing buttons punctures the capsule. After a capsule is punctured, the capsule spins around prior to inhalation of the medicament by a user. The audio sensor detects audio signals for both the spinning of the capsule and the inhalation by the user. For recording an instance of the medicament event, the monitoring attachment awaits confirmation from the limit switches and from the audio sensor.

The figures depict various embodiments of the presented invention for purposes of illustration only.

<FIG> shows an analytics system <NUM> for monitoring accurate, real-time medicament device usage, performing analytics on that data, and providing information about those events, according to one embodiment.

The analytics system includes client computing devices <NUM> (herein referred to as simply "client <NUM>"), a medicament device sensor <NUM> (herein referred to as simply as "sensor <NUM>"), a medicament device <NUM>, an application server <NUM>, a database server <NUM>, and a network <NUM>. Although <FIG> illustrates only a single instance of most of the components of the analytics system <NUM>, in practice more than one of each component may be present, and additional or fewer components may be used in conjunction with the components shown.

The clients <NUM>, at the behest of their users, interact with the analytics system <NUM> via the network <NUM>. For purposes of explanation and clarity it is useful to identify at least two different types of users. A patient <NUM> is a user burdened with a medical challenge who makes use of the analytics system <NUM> at least in part to obtain personalized risk notifications provided by the server <NUM> based on records by the sensor <NUM>. Records recorded by the sensor <NUM> may include rescue and controller events involving rescue and controller medicament dispensing, respectively, by one or more medicament devices <NUM> (e.g., one for each type of medication). Such notifications can be provided in exchange for the user's permission to allow the analytics system <NUM> to monitor the patient's <NUM> medicament device <NUM> usage. As will be explained below, medication events are detected by a sensor <NUM> associated with the medicament device <NUM> and the user's client <NUM>, which in turn reports to the application server <NUM>, which in turn can initiate a process to generate notifications on the user's medical status as determined by the analytics system <NUM> which may be provided to the user through the client <NUM>.

Another type of user is a healthcare provider <NUM> who, again with the patient's <NUM> express permission, also receives notifications regarding a patient's medicament management. In certain cases, the medicament device is a medical dose inhaler for providing medication, with some medication used for controlling asthma, chronic obstructive pulmonary disease, chronic sinusitis, allergies, another breathing challenge, etc. The patient <NUM> may also express permission for notifications to be shared with a community revolving around medicament usage event data and derived statistics regarding rescue events associated with medicament dispensing and other associated data. Other types of users are also contemplated, such as parents/guardians of patients <NUM> who may also want to receive notifications in the event that their own clients <NUM> are distinct from that of their children.

The client <NUM> is a computer system. An example physical implementation is described more completely below with respect to <FIG>. The client <NUM> is configured to wirelessly communicate with the analytics system <NUM> via network <NUM>. With network <NUM> access, the client <NUM> transmits to the analytics system <NUM> the user's geographical location and the time of a rescue medication event, as well as information describing the event as received from the associated sensor <NUM>.

Regarding user location and event times, the client <NUM> may determine the geographical location and time of a rescue event through use of information about the cellular or wireless network <NUM> to which it is connected. For example, the current geographical location of the client <NUM> may be determined by directly querying the software stack providing the network <NUM> connection. Alternatively, the geographical location information may be obtained by pinging an external web service (not shown in <FIG>) made accessible via network <NUM>. The time of an event can be provided by the sensor <NUM> as part of the event data or added to event data by querying an appropriate software routine available as part of the client's <NUM> native operating system.

In addition to communicating with the application server <NUM>, clients <NUM> connected wirelessly to the analytics system <NUM> may also exchange information with other connected clients <NUM>. For example, through a client software application <NUM>, a healthcare provider <NUM> may receive a notification describing a recent rescue event about a patient <NUM>, then in response send a recommendation to the patient <NUM> for post rescue event treatment. Similarly, through application <NUM> patients <NUM> may communicate with their healthcare providers <NUM> and other patients <NUM>.

Application <NUM> provides a user interface (herein referred to as a "dashboard") that is displayed on a screen of the client <NUM> and allows a user to input commands to control the operation of the application <NUM>. The dashboard is the mechanism by which healthcare providers <NUM> and patients <NUM> access the analytics system <NUM>. For example, the dashboard allows patients <NUM> and providers <NUM> to interact with each other, receive rescue event risk notifications, exchange messages about treatment, provide and receive additional event and non-event data, and so on. Application <NUM> may be coded as a web page, series of web pages, or content otherwise coded to render within an internet browser. Application <NUM> may also be coded as a proprietary software program configured to operate on the native operating system of the client <NUM>. The dashboard is more completely described below in conjunction with <FIG>.

In addition to providing the dashboard, application <NUM> may also perform some data processing on rescue event data locally using the resources of client <NUM> before sending the processed data through the network <NUM>. Event data sent through the network <NUM> is received by the application server <NUM> where it is analyzed and processed for storage and retrieval in conjunction with database server <NUM>. The application server <NUM> may direct retrieval and storage request to the database system <NUM> as required by the client application <NUM>.

The client <NUM> communicates with the sensor <NUM> using a network adapter and either a wired or wireless communication protocol, an example of which is the Bluetooth Low Energy (BTLE) protocol. BTLE is a short-ranged, low-powered, protocol standard that transmits data wirelessly over radio links in short range wireless networks. After the sensor <NUM> and client <NUM> have been paired with each other using a BTLE passkey, the sensor <NUM> automatically synchronizes and communicates information relating to medicament device <NUM> usage to the client <NUM>. If the sensor <NUM> hasn't been paired with a client <NUM> prior to a rescue medication event, the information is stored locally until such a pairing occurs. Upon pairing, the sensor <NUM> communicates any stored event records to the client <NUM>. In other implementations, other types of wireless connections are used (e.g., infrared or <NUM>).

Although clients <NUM> and medicament devices <NUM> are described above as being separate physical devices (such as smart phones and inhalers, respectively), in the future it is contemplated the medicament devices <NUM> may include not only sensors <NUM> integrated into a single housing with the device <NUM>, but also aspects of the client <NUM>. For example, a medicament device <NUM> may include an audiovisual interface including a display or other lighting elements as well as speakers for presenting visual audible information. In such an implementation the medicament device <NUM> itself may present the contents of notifications provided by the server <NUM> directly, in place of or in addition to presenting them through the clients <NUM>.

The medicament device <NUM> is a medical device used to deliver medication to the lungs of a user experiencing constricted respiratory airflow. Medicament devices (e.g. inhalers) are typically portable and small enough to be carried by hand for ease of accessibility when treating respiratory attacks. In one embodiment, medicine is delivered in aerosol form through a medicament device <NUM> such as a metered dose inhaler. Metered dose inhalers include a pressured propellant canister of aerosol medicine, a metering valve for delivering a regulated medicine dispensing amount, and a plastic holder that holds the pressurized canister and also forms a mouthpiece for delivery of the medicine. In another embodiment, medicine is delivered in dry powder form through a medicament device <NUM> such as a dry powder inhaler. Dry powder inhalers may have Cartesian ovular shaped bodies that house wheel and gear mechanisms enabling a user to index through a strip of dry powder medication. The bodies of dry powder inhalers also include a manifold and a mouthpiece to deliver dry powder to the user. Examples of controller medications that are dispensed by a controller medicament device <NUM> include beclomethasone, budesonide, and fluticasone as well as combinations of those medications with a long-acting bronchodilator such as salmeterol or formoterol. Examples of rescue medications that are dispensed by a rescue medicament device <NUM> include albuterol, salbutamol, levalbuterol, metaproterenol, and terbutaline.

Each patient may be associated with more than one medicament device <NUM>. For example, the patient may have a rescue medicament device <NUM> that dispenses rescue medication, and a controller medicament device <NUM> that dispenses controller medication. Similarly, each patient may be associated with more than one sensor <NUM>, each chosen to operate with one of the patient's medicament devices <NUM>.

Generally, a sensor <NUM> is a physical device that monitors the usage of the medicament device <NUM>. The sensor <NUM> is either removeably attachable to the medicament device without impeding the operation of the medication dispenser, or the sensor <NUM> is an integrated component that is a native part of the medicament device <NUM> as made available by its manufacturer.

The sensor <NUM> includes its own network adapter (not shown) that communicates with the client <NUM> either through a wired connection, or more typically through a wireless radio frequency connection. In one embodiment, the network adapter is a Bluetooth Low Energy (BTLE) wireless transmitter, however in other embodiments other types of wireless communication may be used (e.g., infrared, <NUM>).

The sensor <NUM> may also be configured to communicate more directly with the application server <NUM>. For example, if the network adapter of the sensor <NUM> is configured to communicate via a wireless standard such as <NUM> or LTE, the adapter may exchange data with a wireless access point such as a wireless router, which may in turn communicate with the application server <NUM> without necessarily involving the client <NUM> in every exchange of data. These two methods of communicating are not mutually exclusive, and the sensor <NUM> may be configured to communicate with both the client <NUM> and the application server <NUM>, for example using redundant transmission to ensure event data arrives at the application server <NUM> or to provide information directly to the client <NUM> while the application server <NUM> is determining what notification to provide in response to an event.

As introduced above, the sensor <NUM> captures data about usage of the medicament device <NUM>. Specifically, each sensor <NUM> captures the time and geographical location of the rescue medication event, that is, usages of the rescue medicament device <NUM>, by the patient <NUM>. Each sensor <NUM> transmits the event data in real-time or as soon as a wireless connection is achieved, automatically without input from the patient <NUM> or health care provider <NUM>. The medication event information is sent to the application server <NUM> for use in analysis, generation of rescue event notifications, and in aggregate analyses of event data across multiple patients.

To accomplish this goal, there are a number of different ways for the sensor <NUM> to be constructed, and in part the construction will depend upon the construction of the medicament device <NUM>. Generally, all sensors <NUM> will include an onboard processor, persistent memory, and the network adapter mentioned above that together function to record, store, and report medication event information to the client <NUM> and/or server <NUM>. Sensors <NUM> may also include a clock for recording the time and date of events and/or a Global Positioning System (GPS) receiver for recording GPS coordinates of the sensors <NUM>.

Regarding specific sensor <NUM> constructions, traditional inhalers, such as mechanical dose counters, are not designed with sensors <NUM> in mind, and thus the sensor <NUM> may be constructed accordingly. Some implementations in this manner include mechanical, electrical, or optical sensors to detect movement of the device <NUM>, priming of the device, activation of the device, inhalation by the user, etc. In contrast, modern inhalers, such as deflectable membrane dose counters, include electrical circuitry that may report event information as an electrical data signal which a sensor <NUM> is designed to receive and interpret, for example the medicament device <NUM> itself may report movement, priming, and activation to the sensor <NUM>.

The sensor <NUM> may store parameters incorporated for use with recording medicament dispensing events by the medicament device <NUM>. Parameters are software, firmware, or hardware data that control settings or specific instruction sets to be carried out by the computing architecture of the medicament device <NUM>. Example parameters include, but are not limited to: (i) medicament dispensing reminder times, delays, or other similar settings, (ii) personalized audio ringtones for playback on an audio speaker of a medicament device, in some instances in association with particular device functions, (iii) software instructions for controlling the operation of the sensor <NUM> function, (iv) calibration and configuration values for sensing and output components, and (v) unique device identifiers, authentication keys, and encryption keys. Some or all of the parameters of the sensor <NUM> may be stored in the client <NUM>. The client <NUM> communicates with the sensor <NUM> when parameters are updated, so that the client <NUM> can transmit the updated parameters for storage within and use by the sensor <NUM>.

More information regarding hardware and software components for the sensors <NUM> and medicament devices <NUM>, as well as the interaction between them to record rescue medication events can be found in <CIT>, and <CIT>.

The application server <NUM> is a computer or network of computers. Although a simplified example is illustrated in <FIG>, typically the application server will be a server class system that uses powerful processors, large memory, and faster network components compared to a typical computing system used, for example, as a client <NUM>. The server typically has large secondary storage, for example, using a RAID (redundant array of independent disks) array and/or by establishing a relationship with an independent content delivery network (CDN) contracted to store, exchange and transmit data such as the asthma notifications contemplated above. Additionally, the computing system includes an operating system, for example, a UNIX operating system, LINUX operating system, or a WINDOWS operating system. The operating system manages the hardware and software resources of the application server <NUM> and also provides various services, for example, process management, input/output of data, management of peripheral devices, and so on. The operating system provides various functions for managing files stored on a device, for example, creating a new file, moving or copying files, transferring files to a remote system, and so on.

The application server <NUM> includes a software architecture for supporting access and use of analytics system <NUM> by many different clients <NUM> through network <NUM>, and thus at a high level can be generally characterized as a cloud-based system. The application server <NUM> generally provides a platform for patients <NUM> and healthcare providers <NUM> to report data recorded by the sensors <NUM> associated with their medicament devices <NUM> including both rescue medication and controller medication events, collaborate on medication treatment plans, browse and obtain information relating to their condition and geographic location, and make use of a variety of other functions.

Generally, the application server <NUM> is designed to handle a wide variety of data. The application server <NUM> includes logical routines that perform a variety of functions including checking the validity of the incoming data, parsing and formatting the data if necessary, passing the processed data to a database server <NUM> for storage, and confirming that the database server <NUM> has been updated.

The application server <NUM> stores and manages data at least in part on a patient by patient basis. Towards this end, the application server <NUM> creates a patient profile for each user. The patient profile is a set of data that characterizes a patient <NUM> of the analytics system <NUM>. The patient profile may include identifying information about the patient such as age, gender, current rescue medication, current controller medication, notification preferences, a controller medication adherence plan, a patient's relevant medical history, and a list of non-patient users authorized to access the patient profile. The profile may further specify a device identifier, such as a unique media access control (MAC) address identifying the one or more clients <NUM> or sensors <NUM> authorized to submit data (such as controller and rescue medication events) for the patient.

The profile may specify which different types of notifications are provided to patients <NUM> and their personal healthcare providers <NUM>, as well as the frequency with which notifications are provided. For example, a patient <NUM> may authorize a healthcare provider <NUM> to receive notifications indicating a rescue event. The patient <NUM> may also authorize their healthcare provider <NUM> be given access to their patient profile and rescue event history. If the healthcare provider <NUM> is provided access to the patient profile of the patient <NUM>, the healthcare provider may specify controller adherence or rescue medication plans. Medication plans may include a prescribed number of doses per day for controller medications.

The application server <NUM> also creates profiles for health care providers <NUM>. A health care provider profile may include identifying information about the health care provider <NUM>, such as the office location, qualifications and certifications, and so on. The health care provider profile also includes information about their patient population. The provider profile may include access to all of the profiles of that provider's patients, as well as derived data from those profiles such as aggregate demographic information, rescue and controller medication event patterns, and so on. This data may be further subdivided according to any type of data stored in the patient profiles, such as by geographic area (e.g., neighborhood, city) or by time period (e.g., weekly, monthly, yearly).

The application server <NUM> receives rescue medication event information from the client <NUM> or the sensor <NUM>, triggering a variety of routines on the application server <NUM>. In the example implementations described below, the data analysis module <NUM> executes routines to access asthma event data as well as other data including a patient's profile, analyze the data, and output the results of its analysis to both patients <NUM> and healthcare providers <NUM>. This process is generally referred to as an asthma risk analysis. The asthma risk analysis may be performed at any point in time, in response to a rescue event, due to a relevant change in the patient's environment, and in response to any one of a number of triggering conditions discussed further below.

Other analyses are also possible. For example, a risk analysis may be performed on rescue and controller medication use for multiple patients to identify based on spatial/temporal clusters (or outbreaks) of medication use based on historically significant permutations from individual, geographic, clinical, epidemiologic, demographic, or spatial or temporal baselines or predicted or expected values. Other types of analyses may include daily/weekly adherence trends, adherence changes over time, adherence comparisons to other relevant populations (e.g., all patients, patients on a particular rescue medication or controller medication or combination thereof, identification of triggers (spatial, temporal, environmental), rescue use trends over time, and rescue use comparisons to other relevant populations.

Responsive to any analyses performed, the application server <NUM> prepares and delivers push notifications to send to patients <NUM>, authorized healthcare providers <NUM>, and/or other users provided access to the patient's profile. Notifications can provide details about the timing, location, and affected patient(s) <NUM> involved in a medication rescue event. Notifications may additionally comprise a distress or emergency signal that requests emergency assistance that is distributed to emergency assistance providers <NUM>. Notifications may also include the results of the asthma risk analysis performed by the data analysis module <NUM>. More information regarding the types of notifications that may be sent and the content they may contain is further described below.

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

Notifications are provided through the network <NUM> to client applications <NUM> in a data format specifically designed for use with the client applications, and additionally or alternatively may be provided as short message service (SMS) messages, emails, phone calls, or in other data formats communicated using other communication mediums.

The database server <NUM> stores patient and provider related data such as profiles, medication events, patient medical history (e.g., electronic medical records). Patient and provider data is encrypted for security and is at least password protected and otherwise secured to meet all Health Insurance Portability and Accountability Act (HIPAA) requirements. Any analyses (e.g., asthma risk analyses) that incorporate data from multiple patients (e.g., aggregate rescue medication event data) and are provided to users is de-identified so that personally identifying information is removed to protect patient privacy.

The database server <NUM> also stores non-patient data used in asthma risk analyses. This data includes regional data about a number of geographic regions such as public spaces in residential or commercial zones where patients are physically located and may be exposed to pollutants. This data may specifically include or be processed to obtain a patient's proximity to green space (areas including concentrated numbers of trees and plants). One example of regional data includes georeferenced weather data, such as temperature, wind patterns, humidity, the air quality index, and so on. Another example is georeferenced pollution data, including particulate counts for various pollutants at an instance of time or measured empirically. The regional data includes information about the current weather conditions for the time and place of the rescue event such as temperature, humidity, and air quality index. All of the items of data above may vary over time, and as such the data itself may be indexed by time, for example separate data points may be available by time of day (including by minute or hour), or over longer periods such as by day, week, month, or season. Although the database server <NUM> is illustrated in <FIG> as being an entity separate from the application server <NUM> the database server <NUM> may alternatively be a hardware component that is part of another server such as server <NUM>, such that the database server <NUM> is implemented as one or more persistent storage devices, with the software application layer for interfacing with the stored data in the database is a part of that other server <NUM>.

The database server <NUM> stores data according to defined database schemas. Typically, data storage schemas across different data sources vary significantly even when storing the same type of data including cloud application event logs and log metrics, due to implementation differences in the underlying database structure. The database server <NUM> may also store different types of data such as structured data, unstructured data, or semi-structured data. Data in the database server <NUM> may be associated with users, groups of users, and/or entities. The database server <NUM> provides support for database queries in a query language (e.g., SQL for relational databases, JSON NoSQL databases, etc.) for specifying instructions to manage database objects represented by the database server <NUM>, read information from the database server <NUM>, or write to the database server <NUM>.

The network <NUM> represents the various wired and wireless communication pathways between the client <NUM> devices, the sensor <NUM>, the application server <NUM>, and the database server <NUM>. Network <NUM> uses standard Internet communications technologies and/or protocols. Thus, the network <NUM> can include links using technologies such as Ethernet, IEEE <NUM>, integrated services digital network (ISDN), asynchronous transfer mode (ATM), etc. Similarly, the networking protocols used on the network <NUM> can include the transmission control protocol/Internet protocol (TCP/IP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network <NUM> can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), JavaScript Object Notation (JSON) etc. In addition, all or some links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), Secure HTTP (HTTPS) and/or virtual private networks (VPNs). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

<FIG> is a high-level block diagram illustrating physical components of an example computer <NUM> that may be used as part of a client <NUM>, application server <NUM>, and/or database server <NUM> from <FIG>, according to one embodiment. Illustrated is a chipset <NUM> coupled to at least one processor <NUM>. Coupled to the chipset <NUM> is volatile memory <NUM>, a network adapter <NUM>, an input/output (I/O) device(s) <NUM>, a storage device <NUM> representing a non-volatile memory, and a display <NUM>. In one embodiment, the functionality of the chipset <NUM> is provided by a memory controller <NUM> and an I/O controller <NUM>. In another embodiment, the memory <NUM> is coupled directly to the processor <NUM> instead of the chipset <NUM>. In some embodiments, memory <NUM> includes high-speed random access memory (RAM), such as DRAM, SRAM, DDR RAM or other random access solid state memory devices.

The storage device <NUM> is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory <NUM> holds instructions and data used by the processor <NUM>. The I/O device <NUM> may be a touch input surface (capacitive or otherwise), a mouse, track ball, or other type of pointing device, a keyboard, or another form of input device. The display <NUM> displays images and other information from the computer <NUM>. The network adapter <NUM> couples the computer <NUM> to the network <NUM>.

As is known in the art, a computer <NUM> can have different and/or other components than those shown in <FIG>. In addition, the computer <NUM> can lack certain illustrated components. In one embodiment, a computer <NUM> acting as server <NUM> may lack a dedicated I/O device <NUM>, and/or display <NUM>. Moreover, the storage device <NUM> can be local and/or remote from the computer <NUM> (such as embodied within a storage area network (SAN)), and, in one embodiment, the storage device <NUM> is not a CD-ROM device or a DVD device.

Generally, the exact physical components used in a client <NUM> will vary in size, power requirements, and performance from those used in the application server <NUM> and the database server <NUM>. For example, clients <NUM>, which will often be home computers, tablet computers, laptop computers, or smart phones, will include relatively small storage capacities and processing power, but will include input devices and displays. These components are suitable for user input of data and receipt, display, and interaction with notifications provided by the application server <NUM>. In contrast, the application server <NUM> may include many physically separate, locally networked computers each having a significant amount of processing power for carrying out the asthma risk analyses introduced above. In one embodiment, the processing power of the application server <NUM> provided by a service such as Amazon Web Services™. Also in contrast, the database server <NUM> may include many, physically separate computers each having a significant amount of persistent storage capacity for storing the data associated with the application server.

As is known in the art, the computer <NUM> is adapted to execute computer program modules for providing functionality described herein. A module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device <NUM>, loaded into the memory <NUM>, and executed by the processor <NUM>.

The dashboard, for example dashboard <NUM> illustrated in <FIG>, allows users to interact with the analytics system <NUM>. The dashboard <NUM> provides a means to transfer information on a user-to-user (e.g., patient <NUM> to healthcare provider <NUM>) or user-to-system / system-to-user basis. Dashboards <NUM> are accessed through the client application <NUM> on the client <NUM> and provide a mechanism for both patients and healthcare providers to monitor medication rescue events, exchange personalized patient healthcare information, and receive notifications such as rescue event risk notifications. Patients <NUM> may communicate with other healthcare providers <NUM> and other patients <NUM> through the dashboard <NUM>, for example, to discuss and share information about breathing challenges, medication usage, or breathing challenge management. The ability to share healthcare information may give patients or healthcare care providers experiencing a similar issue a way to share individual perspectives.

The dashboard <NUM> also allows authorized healthcare providers <NUM> to access a list of patients to view, annotate, update, interact with, and export information about patient and community data and statistics in various demographics or geographic segments. Using the dashboard <NUM>, healthcare providers are able to monitor patients <NUM> individually or in aggregate, to receive and provide feedback on how their associated patient populations are responding to breathing challenge management guidance. A healthcare provider <NUM> who has access to individual or multiple patients <NUM> has the ability to establish notification thresholds, set parameters for the notifications, and receive notifications when patients' <NUM> event history matches certain conditions (e.g. rescue event). Additionally, the dashboard <NUM> can receive and display regular reports of event patterns for specific demographics generated by the analytics system <NUM>.

The dashboard <NUM> presents a variety of information including tabular data, graphical visualizations, and analyses to users through display "cards" <NUM>. Display cards <NUM> are conformably suited to smaller displays typical of portable clients <NUM>, for example mobile phones or tablets, and include "bite size" pieces of information that mimic the simplistic organizational style found in baseball cards. The dashboard <NUM> may also include a system menu <NUM> that allows users to navigate through different categories of healthcare information.

Notifications provided by the application server <NUM> are related to the display cards <NUM>. Generally, notifications include not only information to be presented to the user through the application <NUM>, but also parameters for specifying which display card <NUM> is to be used to display the contents of the notification. Any information pushed/pulled from the application server <NUM> may be associated with one or more cards. For example, a notification can be pushed to the patient based on the outcome of an risk analysis. The dashboard <NUM> will process the notification and determine which card/s to use to present the information in the notification. Continuing the example, the recipient of the notification may make a request to pull data from the application server <NUM>. The application server <NUM> provides the requested data in another notification, and the dashboard <NUM> then determines which display card <NUM> to display the requested information.

The dashboard <NUM> may provide a variety of different display cards <NUM>, which may be organized into categories. An information card type includes cards that display data. Information cards may, for example, display medication rescue events, statistics, and maps including both patient data and community data. Information cards are further sub-categorized into event, trend, education, and alert display cards.

Event cards include data relating to rescue medication events, such as a list of historical medication rescue events for a specific patient, or patient rescue event data overlaid on a geographical map for a specific provider.

<FIG> is a perspective view of a medicament device sensor <NUM>, according to one embodiment. The medicament device sensor <NUM> is a monitoring attachment for a single-dose dry powder inhaler (DPI), where the sensor <NUM> includes various sensors for accurately recording an instance of medicament dispensing by the DPI. The medicament device sensor <NUM> comprises a body <NUM> and two walls - a front wall <NUM> and a back wall <NUM>. The body <NUM> has an internal housing which can store various computing components for the monitoring attachment and a bottom surface <NUM> where various sensors are coupled to for monitoring use of the DPI. In various other embodiments, the medicament device sensor <NUM> may be coupled to other types of inhalers, not just the DPI. In these other embodiments, the same principles disclosed within this present disclosure may be applied in the embodiments of medicament device sensors coupling to other types of inhalers. <FIG> is a perspective view of the medicament device sensor <NUM> attached to a DPI <NUM>, according to one embodiment.

The body <NUM>, the front wall <NUM> and the back wall <NUM> are composed of a lightweight, sturdy material. Example materials include thermoplastics, thermosets, polymers, composites, or some combination thereof. The shape of the body <NUM> with the front wall <NUM> and the back wall <NUM> has mirror symmetry in one dimension and asymmetry in the other two dimensions. The asymmetry in at least two dimensions provides a single orientation with which the medicament device sensor <NUM> attaches to the medicament device <NUM>. The front wall <NUM> also contains a securement clip <NUM> which will be further described in conjunction with <FIG> & <NUM>.

On either side of the mirror symmetry plane, the front wall <NUM> and the back wall <NUM> extend upward leaving symmetrical slots <NUM> on either side of the mirror symmetry plane. The slots <NUM> on either side are shaped and oriented so as to receive corresponding protrusions on a portion of a bottom surface of the medicament device <NUM>. The portion of the medicament device <NUM> with the protrusions has matching symmetry to that of the attachment. The complementary shapes of the attachment side wall, including the bottom surface of the body <NUM>, the front wall <NUM>, and the back wall <NUM> provide the single orientation for the medicament device sensor <NUM> to securely attach onto the portion of the medicament device <NUM>.

In some embodiments, the back wall <NUM> includes a protrusion <NUM> which holds the medicament device <NUM> in place when the medicament device sensor <NUM> is attached to the medicament device <NUM>. In <FIG>, the back wall <NUM> includes a slit <NUM> allowing a protrusion <NUM> of the back wall <NUM> above the slit <NUM> to flex more easily. When the medicament device <NUM> is coupled to the medicament device sensor <NUM>, the protrusion <NUM> of the back wall <NUM> contacts the medicament device <NUM> to hold the medicament device <NUM> in place. When a user applies a decoupling force on the medicament device <NUM> against the medicament device sensor <NUM>, the protrusion <NUM> of the back wall <NUM> can flex outward away from the medicament device <NUM> allowing the medicament device <NUM> to be easily removed from the medicament device sensor <NUM>. The protrusion <NUM> of the back wall <NUM> being used for securing the medicament device sensor <NUM> to the medicament device <NUM> will be further described in conjunction the discussion of the securement clip <NUM> in <FIG> & <NUM>.

<FIG> is a top-plan view of the medicament device sensor <NUM>, according to one embodiment. The medicament device sensor <NUM> is configured to record and to report medicament dispensing events by the medical inhaler to which it is attached as described above in reference to I. MEDICAMENT DEVICE AND SENSOR. The medicament device sensor <NUM> includes an audio sensor <NUM> and multiple pressure sensors <NUM>. Although not shown, the medicament device sensor <NUM> also includes a battery, a wireless transmitter and receiver (e.g., a Bluetooth transceiver), a non-transitory computer-readable storage medium, and a computer processor. These various components are placed in the internal housing of the body <NUM>. Although this description and the example embodiments describe the medicament device sensor <NUM> with the above listed components, other embodiments may include additional or fewer components while maintaining the principles described herein. For example, instead of a Bluetooth transmitter and receiver, the medicament device sensor <NUM> could more generally contain a wireless transmitter and receiver using other mediums and/or formats of wireless communication with a remote computing device.

As introduced above, the medicament device sensor <NUM> comprises the body <NUM> with a bottom surface <NUM> and an internal housing. In <FIG>, only the bottom surface <NUM> is viewable. Along the bottom surface <NUM>, the medicament device sensor <NUM> has at least one audio sensor <NUM> placed on the bottom surface <NUM> of the body <NUM> which is configured to detect audio signals corresponding to various functions of the medicament device <NUM> from the bottom of the medicament device <NUM>. Multiple pressure sensors <NUM> placed on the bottom surface <NUM> of the body <NUM> are configured to detect pressure associated with other functions of the medicament device <NUM> in tandem or in sequence with the audio sensor <NUM>.

The audio sensor <NUM> detects sounds corresponding to a spinning of a capsule containing medicament by the medicament device <NUM> prior to inhalation and sounds corresponding to inhalations during medicament dispensing events. As a user presses one or both dosing buttons on the medicament device <NUM>, the medicament device <NUM> punctures a single-dose capsule of dry powder medicament. Prior to inhalation, the single-dose capsule is spun in a chamber of the medicament device <NUM>. The audio sensor <NUM> records an acoustic intensity of the single-dose capsule spinning in the chamber. The detected spinning of the single-dose capsule is indicative of presence of the single-dose capsule within the medicament device <NUM>. In addition to or in isolation of recording the spinning of the capsule containing the medicament, the audio sensor <NUM> records an inhalation indicative of medicament dispensing as a medicament dispensing event.

The inhalation represents confirmation of successful medicament dispensing by the medicament device <NUM>. The audio sensor <NUM> can send audio files of the inhalation corresponding with medicament dispensing events to the processor. The processor, in turn, can send the audio files to a remote computing device via a wireless transmitter for analysis on the remote computing system. In other embodiments, the audio sensors <NUM> can be further configured to detect audio corresponding to other functions of the medicament device sensor <NUM>.

The multiple pressure sensors <NUM> detects securement of the medicament device sensor <NUM> and activation of medicament dispensing by the medicament device <NUM> through detection of pressing of medicament device <NUM> dosing buttons that cause medicament dispensing. In some embodiments, the plurality of pressure sensors <NUM> comprises limit switches. The limit switches operate to detect pressure when pressed; however, the limit switches have a maximum limit as to how far the limit switches press. Once any depression is sensed, the limit switch signals the detection of depression.

Of the multiple of pressure sensors <NUM>, there is a center pressure sensor arranged on the bottom surface <NUM> of the body <NUM> of the medicament device sensor <NUM> so as to cause the bottom surface of the medicament device <NUM> to press the center pressure sensor. As the medicament device <NUM> presses the center pressure sensor, the center pressure sensor detects attachment of the medicament device sensor <NUM> to the medicament device. The depression of the center pressure sensor can then be reported to the processor as confirmation of secure attachment.

There are also two pressure sensors of the plurality of pressure sensors <NUM> which are coupled to dosing buttons on the medicament device <NUM>, and are aligned underneath the medicament dosing buttons of the medicament device <NUM>. Each pressure sensor corresponds to one dosing button to detect depression of that button. When one or both of the dosing buttons are depressed by a patient, the medicament device <NUM> pierces the single-dose capsule thus priming the medicament for dispensing by the medicament device <NUM>. The two pressure sensors confirm pressing of the dosing buttons thereby indicating priming of the medicament.

The processor coordinates recording and activation of the audio sensor <NUM> and the plurality of pressures sensors <NUM>. When one pressure sensor detects attachment of the medicament device sensor <NUM> to the medicament device <NUM>, the processor can activate the audio sensor <NUM>, remaining pressure sensors of the plurality of pressure sensors <NUM>, the GPS receiver, the Bluetooth transmitter and receiver, or some combination thereof. The processor may notify a client <NUM> a confirmation of secure attachment of the medicament device sensor <NUM> to the medicament device <NUM> as detected by the center pressure sensor. The processor can receive confirmation from the two or more pressure sensors configured to detect depression of the medicament device <NUM> dosing buttons. Then the processor can activate the audio sensor <NUM> for audio confirmation of an inhalation associated with the dispensing of medicament by the medicament device <NUM>. Alternately, the processor can record a medicament dispensing event if one or more pressure sensors indicates depression of limit switches and an inhalation is confirmed by the audio sensor <NUM>.

The processor may additionally record with each medicament dispensing event a time of the event and may also record geographical location coordinates as received by a GPS receiver or other similar component (implemented in software, hardware, or firmware). The processor stores these medicament dispensing events as event records on the computer-readable storage medium. Then the processor activates the Bluetooth transmitter and receiver so as to communicate event records from the computer-readable storage medium to the client <NUM>.

<FIG> is a perspective view of a portion of the medicament device sensor <NUM> with the securement clip <NUM>; <FIG> is a cross sectional view of the securement clip <NUM>. The securement clip <NUM> is placed on the front wall <NUM> of the medicament device sensor <NUM> and clips over a ledge <NUM> on the medicament device <NUM> shown in <FIG>. When the medicament device sensor <NUM> slides onto the medicament device <NUM> in the one orientation due to restriction by the front wall <NUM> and the back wall <NUM>, the securement clip <NUM> bends around the medicament device <NUM> until it clips on the ledge <NUM> of the medicament device <NUM>. When the securement clip <NUM> is clipped onto the ledge <NUM> of the medicament device <NUM>, the medicament device sensor <NUM> is securely attached to the medicament device <NUM>. Additionally, the protrusion on the back wall <NUM> as shown in <FIG> is in contact with the medicament device <NUM> so as to ensure that the ledge <NUM> is pressed against the front wall <NUM> with the securement clip <NUM>.

To detach the medicament device sensor <NUM>, there is a securement clip release tab <NUM> which aids in bending the securement clip <NUM> away from the ledge <NUM> of the medicament device <NUM>. When a release force <NUM> is applied on the securement clip release tab <NUM>, there is a rotation <NUM> of securement clip <NUM> around a pivot point <NUM> denoted by the dashed oval in <FIG>. The rotation <NUM> bends the securement clip <NUM> away from the ledge <NUM> of the medicament device <NUM> such that the medicament device sensor <NUM> may slide out from the medicament device <NUM>. In the illustration of <FIG>, once the securement clip <NUM> bends away from the ledge <NUM>, the medicament device <NUM> can slide vertically relative to the medicament device sensor <NUM>. With one securement clip <NUM> and one corresponding ledge on the medicament device <NUM>, the securement clip <NUM> insures attachment of the medicament device sensor <NUM> in the proper orientation.

In additional embodiments, the positioning of the securement clip <NUM> can vary along the front wall <NUM>. Similarly in alternate embodiments, the dimensions of the securement clip <NUM> can vary so as to provide a longer clip for clipping on the ledge <NUM> of the medicament device <NUM>. In some embodiment, the securement clip <NUM> is composed of a durable and flexible material. The flexibility of the securement clip <NUM> provides the ability of the securement clip <NUM> to bend around the ledge <NUM>. The durability of the securement clip <NUM> insures that the securement clip <NUM> doesn't deform when the release force <NUM> is applied to the securement clip release tab <NUM>.

Although the discussion above focuses on asthma specifically, all systems and processes described herein are equally applicable to chronic obstructive pulmonary disease (COPD) and chronic respiratory disease (CRD) generally, and consequently can also be used to assist in treatment of COPD and CRD, as well as asthma.

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

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

Claim 1:
A medicament device sensor (<NUM>) configured for removable attachment to a medicament device (<NUM>), the medicament device sensor (<NUM>) comprising:
a body (<NUM>) comprising a first wall, a second wall, and a bottom surface:
the bottom surface (<NUM>) configured to mate to a complementary outer surface of a medicament device (<NUM>); and
the first wall coupled to an edge of the bottom surface (<NUM>) and comprising:
a securement clip (<NUM>) configured to attach the first wall of the medicament device sensor (<NUM>) to a ledge (<NUM>) on a complementary surface of the medicament device (<NUM>) in a fixed orientation;
characterized by
a release tab (<NUM>) having a topmost surface contiguous with a topmost surface of the first wall, the release tab (<NUM>) configured to rotate the securement clip (<NUM>) when pressed such that the medicament device (<NUM>) can slide relative to the medicament device sensor (<NUM>); and
one or more sensors coupled to the bottom surface (<NUM>), each of the one or more sensors configured to signals indicating a use of the medicament device (<NUM>).