Patent Grant
11938265
The present invention relates generally to devices, systems, and methods for adherence monitoring and patient interaction.
Asthma is the most common chronic disease and is one of the leading causes of hospitalization for American children. Nearly ten million—or one in seven—kids in America are affected by asthma. Worrisome for children and parents alike, asthma is also a pressing public health issue, costing the U.S. over $15 billion annually. Asthma is also a serious concern for adults in the U.S. and for both adults and children outside the U.S. Additionally, air quality problems throughout the world, particularly in large, congested cities, can exacerbate asthma and other respiratory problems and can generally increase the prevalence of and the need for treating such respiratory health issues.
Inhaled maintenance medication, e.g., corticosteroids, can effectively control asthma symptoms. Such medication is typically prescribed for administration on a regular, usually daily, schedule. The closer a patient adheres to the medication schedule, the better the patient's condition can be managed, e.g., because adequate amounts of the medication can be consistently present in the patient's system to consistently control adverse effects of the asthma. Medications other than those for asthma treatment, such as for other respiratory conditions, for dermatological issues, for cardiac issues, etc., can also be prescribed for dosage on a regular schedule and can have their maximized effectiveness if taken on the regular schedule.
It can be difficult for patients to adhere to their medication treatment schedule for a variety of reasons, such as unfamiliarity with a new medication treatment schedule, being busy with an activity such as work, school, napping, or athletics, and simply forgetting to take the medication on schedule. It can be particularly difficult for children to remember to take their medication on schedule, particularly if any medication doses are required while a child is away from their parent or guardian, such as during school or while at summer camp. Non-adherence to a prescribed schedule of medication can cause any number of adverse effects, such as unnecessary exacerbations, repeating symptoms, required doses of emergency treatment medication, and/or hospital emergency room visits. Adhering to a medication schedule can thus help better maintain a patient's health, help reduce instances of emergency medication administration, and/or help reduce health care costs by requiring fewer emergency hospital visits or other medical practitioner consultations.
Accordingly, there remains a need for improved devices, systems, and methods for adherence monitoring and patient interaction.
In one embodiment, an apparatus is provided that includes a mechanical accessory attached to a medication dispenser containing a medication that is dispensable to a patient. The accessory can include a processor configured to cause the accessory to provide a notification to the patient when a dosage of the medication is due according to a predetermined medication schedule, a sensor configured to sense when the medication is dispensed to the patient, a memory, and a wireless communication mechanism. The sensing of the medication being dispensed can trigger the processor to store data in the memory regarding dispensing of the medication. The processor can be configured to cause the wireless communication mechanism to wirelessly transmit the stored data to an external device that is external to the accessory and the medication dispenser.
The stored data can include at least one of a date and time when the medication was dispensed, a time elapsed between consecutive dispensing of the medication, a time elapsed between dispensing of the medication and the transmitting to an external device, orientation of the medication dispenser when the medication was dispensed, a temperature of the medication when the medication was dispensed, movement of the medication dispenser when the medication was dispensed, and an amount of the medication dispensed.
The processor can be configured to cause the wireless communication mechanism to wirelessly transmit the stored data in response to a data request received from the external unit, and/or the processor can be configured to cause the wireless communication mechanism to automatically wirelessly transmit the stored data to the external unit in real time with the sensing of the medication being dispensed.
The notification can include at least one of an illuminated light, an audible sound, a vibration, a change in temperature of the accessory, a text message, an email message, and a phone call.
When the medication is not dispensed within a predetermined period of time after the notification is provided, the processor can be configured to cause a missed dosage notation to be saved in the memory. The wireless communication mechanism can be configured to wirelessly transmit the stored missed dosage notation to an external device.
When the medication is not dispensed within a predetermined period of time after the notification is provided, the processor can be configured to cause the accessory to provide an alarm. The alarm can include at least one of an illuminated light, an audible sound, a vibration, a change in temperature of the accessory, a text message, an email message, and a phone call.
The sensor can include at least one of a button configured to be manually depressed, a motion sensor configured to sense movement of the mechanical accessory, a pH sensor configured to sense a pH at a location where the medication is dispensed from the medication dispenser, a temperature sensor configured to sense a temperature of the medication dispenser, and an audio sensor configured to sense a sound of medication dispensing.
The accessory can vary in any number of ways. For example, the accessory can be configured to be removably and replaceably attached to the medication dispenser, or the accessory can be integrally attached to the medication dispenser. For another example, the medication dispenser can include a respiratory inhaler, and the accessory can include a cap removably and replaceably attached to a portion of the inhaler that is depressible by a user so as to dispense the medication such that depressing the cap causes the medication to be dispensed. For another example, the accessory can be removably and replaceably attached to the medication dispenser by at least one of press fit, a magnet, Velcro®, a guide track, a clip, and a strap. For yet another example, the accessory can be configured to be pressed so as to cause the medication to be dispensed. For another example, the accessory can include a power source configured to provide power for the sensor, for the storage of the data, and for the wireless transmission.
In another aspect, a system is provided that in one embodiment includes the provided apparatus and external device. The external device can be configured to generate a report based on the data received from the accessory regarding a plurality of times the medication is dispensed, and the external device can be configured to provide the report to a user. The user can include at least one of the patient, a family member of the patient, and a care provider for the patient.
The system can have any number of variations. For example, the report can include at least one of a summary of the patient's adherence to the predetermined medication schedule, a prediction of changes in the patient's health, a prediction of the patient's future adherence to the predetermined medication schedule, a log of the patient's missed dosages, a log indicating any times a second medication is dispensed off the predetermined medication schedule, a log of successful attempts of the wireless communication mechanism wirelessly communicating data to the external device, and a comparison of the patient's adherence to the predetermined medication schedule with a plurality of other patients' adherence with their respective predetermined medication schedules.
In another embodiment, an apparatus is provided that includes a mechanical accessory attached to a medication dispenser containing a medication that is dispensable to a patient. The accessory can include a sensor configured to sense when the medication is dispensed to the patient, a processor, a memory, and a power source. The sensing of the medication being dispensed can trigger the processor to store data in the memory regarding dispensing of the medication. The power source can have a first state in which the power source does not provide adequate power to the processor to allow data to be stored in the memory, and a second state in which the power source does provide adequate power to the processor to allow data to be stored in the memory. The power source can be configured to move from the first state to the second state in response to the sensor sensing the medication being dispensed, and the power source can be configured to move from the second state to the first state in response to storage of the data in the memory.
The accessory can be configured to be removably and replaceably attached to the medication dispenser, or the accessory can be integrally attached to the medication dispenser.
The accessory can include a timer configured to track passage of time and determine based on the tracked time when a dosage of the medication is due according to a predetermined medication schedule, and a notification mechanism configured to provide a notification to the patient when the dosage of the medication is due. The power source in the first state and in the second state can be configured to continuously provide power to the timer, and the power source can be configured to only provide power to the notification mechanism in the second state so as to allow the notification mechanism to provide the notification. The notification can include at least one of an illuminated light, an audible sound, a vibration, a change in temperature of the accessory, a text message, an email message, and a phone call.
The accessory can include a wireless communication mechanism configured to wirelessly transmit data stored in the memory to an external device that is external to the accessory and the medication dispenser. The power source in the first state can not provide adequate power to the wireless communication mechanism to allow the wireless communication mechanism to wirelessly transmit data. The power source in the second state can provide adequate power to the wireless communication mechanism to allow the wireless communication mechanism to wirelessly transmit data. The power source in the second state can be configured to provide all power for the wireless transmission by the wireless communication mechanism. The power source can be configured to move from the first state to a third state in response to a request for data from the external device. The power source in the third state can be configured to provide adequate power to the wireless communication mechanism to allow the wireless communication mechanism to wirelessly transmit data to the external device in response to the request for data. The power source can be configured to move from the third state to the first state in response to the wireless communication mechanism wirelessly transmitting data to the external device in response to the request for data.
The medication dispenser can include a respiratory inhaler, and the accessory can include a cap removably and replaceably attached to a portion of the inhaler that is depressible by a user so as to dispense the medication such that depressing the cap causes the medication to be dispensed.
In another aspect, a system is provided that includes the provided apparatus and external device. The accessory can include a wireless communication mechanism configured to wirelessly transmit data stored in the memory to an external device that is external to the accessory and the medication dispenser, and the external device can be configured to provide all power for the wireless transmission by the wireless communication mechanism. The system can have any number of variations.
In another embodiment, a system is provided that includes a mechanical accessory and a processor. The accessory can be attached to a medication dispenser containing a medication that is dispensable to a patient. The processor can be configured to cause the accessory to provide a notification to the patient when a dosage of the medication is due according to a predetermined medication schedule, log each instance of the medication being dispensed from the dispenser, determine the patient's compliance with the predetermined medication schedule based on the logged instances, and cause a report indicating the patient's compliance to be provided on a display screen.
The system can vary in any number of ways. For example, the accessory can be configured to be removably and replaceably attached to the medication dispenser, or the accessory can be integrally attached to the medication dispenser. For another example, the notification can include at least one of an illuminated light, an audible sound, a vibration, a change in temperature of the accessory, a text message, an email message, and a phone call. For another example, the report can indicate when the medication is not dispensed within a predetermined period of time after the notification is provided. The medication not being dispensed within the predetermined period of time can indicate a lack of compliance with the predetermined medication schedule. For yet another example, the report can indicate when the medication is dispensed at a date and time inconsistent with the predetermined medication schedule. For another example, the report can indicate at least one of a prediction of changes in the patient's health based on the patient's compliance, a prediction of the patient's future adherence to the predetermined medication schedule based on the patient's compliance, and a comparison of the patient's compliance with a plurality of other patients' compliance with their respective predetermined medication schedules. For still another example, the processor can be included in the accessory. For another example, the processor can be included in an external device external to the accessory and the medication dispenser. For another example, the processor can include a first processor included in the accessory and a second processor included in an external device external to the accessory and the medication dispenser. The first processor can be configured to cause the accessory to provide the notification to the patient and to log the instances, and the second processor can be configured to cause the report to be provided on the display screen. For yet another example, the medication dispenser can include a respiratory inhaler, and the accessory can include a cap removably and replaceably attached to a portion of the inhaler that is depressible by a user so as to dispense the medication such that depressing the cap causes the medication to be dispensed.
In another embodiment, a system is provided that includes a mechanical accessory and a processor. The accessory can be attached to a medication dispenser containing a medication that is dispensable to a patient. The processor can be configured to log a date and time for each instance of the medication being dispensed from the dispenser based on an actuation of the accessory, determine the patient's compliance with a predetermined medication schedule based on the logged dates and times, and cause a report indicating the patient's compliance to be provided on a display screen. The report can indicate a progress of the patient toward a goal level of compliance with the predetermined medication schedule.
The system can have any number of variations. For example, the accessory can be configured to be removably and replaceably attached to the medication dispenser, or the accessory can be integrally attached to the medication dispenser. For another example, the report can be customized for a user based on a category of the user, the category being one of the patient, a family member of the patient, and a care provider for the patient. For another example, the processor can be configured to trigger a reward for the patient when the patient reaches the goal level of compliance. The reward can include at least one of a virtual reward for the patient and a physical reward for the patient. For yet another example, the goal level of compliance can be based on a number of times the medication is dispensed within a predetermined amount of time after a dosage of medication is due as indicated by the predetermined medication schedule. For another example, the processor can be configured to cause the accessory to provide a notification to the patient when a dosage of the medication is due according to the predetermined medication schedule. The progress of the patient toward the goal level of compliance can be based on the medication being dispensed within a predetermined time period after the notification is provided. For another example, the processor can be included in the accessory. For yet another example, the processor can be included in an external device external to the accessory and the medication dispenser. For still another example, the processor can include a first processor included in the accessory and a second processor included in an external device external to the accessory and the medication dispenser. The first processor can be configured to log the date and time, and the second processor can be configured to cause the report to be provided on the display screen. For another example, the medication dispenser can include a respiratory inhaler, and the accessory comprises a cap removably and replaceably attached to a portion of the inhaler that is depressible by a user so as to dispense the medication such that depressing the cap causes the medication to be dispensed.
In another aspect, a method for providing and communicating data regarding medication administration is provided that in one embodiment includes causing a mechanical accessory to provide a notification to a patient when a dosage of medication is due according to a predetermined medication schedule. The accessory can include a sensor and a memory. The method can also include sensing with the sensor when the medication is dispensed to the patient. The sensing can trigger data to be stored in the memory regarding the dispensing of the medication. The method can also include wirelessly transmitting the stored data to an external device that is external to the accessory and the medication dispenser. The method can have any number of variations.
In another embodiment, a method for providing and communicating data regarding medication administration is provided that includes causing a mechanical accessory attached to a medication dispenser to provide a notification to a patient when a dosage of medication contained in the dispenser is due according to a predetermined medication schedule, logging each instance of the medication being dispensed from the dispenser, determining the patient's compliance with the predetermined medication schedule based on the logged instances, and causing a report indicating the patient's compliance to be provided on a display screen. The method can have any number of variations.
In another aspect, a method for managing power supplied to a mechanical accessory attached to a medication dispenser is provided that in one embodiment includes, in response to medication being dispensed from a medication dispenser having a mechanical accessory attached thereto, moving a power source of the accessory from a first state to a second state. The power source in the first state can not provide adequate power to a processor of the accessory to allow data to be stored in a memory of the accessory, and the power source in the second state can provide adequate power to the processor to allow data to be stored in the memory. The method can also include, with the power source in the second state, storing data in the memory regarding the dispensing of the medication, and, in response to storage of the data in the memory, moving the power source from the second state to the first state. The method can have any number of variations.
In another aspect, a method for managing data regarding medication administration is provided that in one embodiment includes logging a date and time for each instance of medication being dispensed from a medication dispenser to a patient based on an actuation of a mechanical accessory attached to the medication dispenser, determining the patient's compliance with a predetermined medication schedule based on the logged dates and times, and causing a report indicating the patient's compliance to be provided on a display screen. The report can indicate a progress of the patient toward a goal level of compliance with the predetermined medication schedule. The method can have any number of variations.
The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:
Certain exemplary embodiments will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the devices and methods disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those of ordinary skill in the art will understand that the devices and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention.
Further, in the present disclosure, like-named components of the embodiments generally have similar features, and thus within a particular embodiment each feature of each like-named component is not necessarily fully elaborated upon. Additionally, to the extent that linear or circular dimensions are used in the description of the disclosed systems, devices, and methods, such dimensions are not intended to limit the types of shapes that can be used in conjunction with such systems, devices, and methods. A person skilled in the art will appreciate that an equivalent to such linear and circular dimensions can be easily determined for any geometric shape.
Various exemplary devices, systems, and methods are provided for adherence monitoring and patient interaction. In general, the devices, systems, and methods can facilitate a patient's adherence to a medication schedule and can facilitate monitoring and tracking of the patient's adherence to the medication schedule. The devices, systems, and methods can allow data regarding the patient's historical adherence to the medication schedule to be accessible via a computer system. A user such as the patient, the patient's family, the patient's care provider, a director of a clinical trial involving the patient, etc. can thus access the adherence data even when remotely located from the patient, which can facilitate evaluation and/or modification of the patient's treatment, facilitate evaluation and/or modification of the clinical trial involving the patient, and/or can facilitate incentivizing the patient to adhere to the medication schedule.
In one embodiment, a medical accessory such as a cap is provided that can be configured to attach to existing medication dispensers, such as asthma inhalers, or to be integrated into a custom-made medication dispenser. The cap can include a notification mechanism such as a light source (e.g., a light emitting diode (LED)) configured to light up when the next dose (also referred to herein as a “dosage”) of medication is due, a speaker configured to provide an audible sound when the next dose of medication is due, a vibration mechanism configured to vibrate when the next dose of medication is due, and a temperature-changing element configured to increase or decrease in temperature when the next dose of medication is due. The cap can include an on-board timer configured to trigger the notification mechanism to provide a notification, e.g., light, sound, vibration, etc. The cap can also include a power source, e.g., a battery, configured to power the timer and the notification mechanism. The notification can help patients of any age more easily adhere to their medication schedule. Ailments such as asthma can therefore be better regulated through maintenance treatment, and patients can be less likely to need to resort to unscheduled, emergency treatments, such as use of a rescue inhaler. The cap can include a button configured to detect usage of the dispenser by being pressed down when medication is dispensed from the dispenser so as to “wake up” a processor coupled to the cap. In response to actuation of the button, the processor can be configured to record the date and time of the dispenser's usage in a storage unit, such as an on-board memory. The stored data can be transmitted to an external source, e.g., computer system, that can store the data in a network cloud, where the data can be accessed via a user interface, such as a web interface. The user interface can allow a user to view and/or analyze the patient's medication usage trends. The user interface can be customized for different patient age groups (e.g., children v. adults) and for different users (e.g., patients, parents, doctors, etc.), thereby allowing different users to view and analyze data most effective for their needs and goals, even when the user is remotely located from the patient. The user interface can include a customizable rewards system for patients, parents, and care providers based on adherence to a prescribed medication schedule, which can be particularly effective in encouraging children to regularly take their medication as directed.
The accessory can be, but is not limited to, use with asthma medication. The accessory can be configured to be used in any adherence/compliance application for medication, such as creams for dermatology patients, inhalers for non-asthma respiratory ailments, pill bottles, and medicament tubes.
Any of a variety of users can access, interact with, control, etc. a user interface from any of a variety of locations. For example, as shown in an embodiment illustrated in
It will be appreciated that the user interface can be accessible using one or more security features such that the aspects of the user interface available to any particular user can be determined based on the identity of the user and/or the location from which the user is accessing the user interface. To that end, each user can have a unique username, password, and/or other security credentials to facilitate access to the user interface. The received security parameter information can be checked against a database of authorized users to determine whether the user is authorized and to what extent the user is permitted to interact with the user interface, view stored information, and so forth. Examples of users who can be permitted to access a user interface include patients, potential patients, significant others, friends, and family members of patients or potential patients, surgical technicians, imaging technicians (e.g., x-ray technicians, MRI technicians, etc.), surgeons, nurses, hospital administrators, surgical equipment manufacturer employees, insurance providers, and operating room directors.
The devices, systems, and methods disclosed herein can be implemented using one or more computer systems, which as mentioned above are also referred to herein as interfaces and client stations.
The various elements of the computer system 200 can be coupled to a bus system 212. The illustrated bus system 212 is an abstraction that represents any one or more separate physical busses, communication lines/interfaces, and/or multi-drop or point-to-point connections, connected by appropriate bridges, adapters, and/or controllers. The computer system 200 can also include one or more network interface(s) 206, one or more input/output (I/O) interface(s) 208, and one or more storage device(s) 210.
The network interface(s) 206 can enable the computer system 200 to communicate with remote devices, e.g., other computer systems, over a network, and can be, for example, remote desktop connection interfaces, Ethernet adapters, and/or other local area network (LAN) adapters. The I/O interface(s) 208 can include one or more interface components to connect the computer system 200 with other electronic equipment. For example, the I/O interface(s) 208 can include high speed data ports, such as universal serial bus (USB) ports, 1394 ports, Wi-Fi, Bluetooth, etc. Additionally, the computer system 200 can be accessible to a user, and thus the I/O interface(s) 208 can include display screens, speakers, keyboards, pointing devices, and/or various other video, audio, or alphanumeric interfaces. The storage device(s) 210 can include any conventional unit or medium for storing data in a non-volatile and/or non-transient manner. The storage device(s) 210 can thus hold data and/or instructions in a persistent state, i.e., the value is retained despite interruption of power to the computer system 100. The storage device(s) 210 can include one or more hard disk drives, flash drives, USB drives, optical drives, various media cards, diskettes, compact discs, and/or any combination thereof and can be directly connected to the computer system 200 or remotely connected thereto, such as over a network. In an exemplary embodiment, the storage device(s) can include a tangible or non-transitory computer readable medium configured to store data, e.g., a hard disk drive, a flash drive, a USB drive, an optical drive, a media card, a diskette, a compact disc, etc.
The elements illustrated in
The computer system 200 can include a web browser for retrieving web pages or other markup language streams, presenting those pages and/or streams (visually, aurally, or otherwise), executing scripts, controls and other code on those pages/streams, accepting user input with respect to those pages/streams (e.g., for purposes of completing input fields), issuing Hypertext Transfer Protocol (HTTP) requests with respect to those pages/streams or otherwise (e.g., for submitting to a server information from the completed input fields), and so forth. The web pages or other markup language can be in HyperText Markup Language (HTML) or other conventional forms, including embedded Extensible Markup Language (XML), scripts, controls, and so forth. The computer system 200 can also include a web server for generating and/or delivering the web pages to client computer systems.
In an exemplary embodiment, the computer system 200 can be provided as a single unit, e.g., as a single server, as a single tower, contained within a single housing, etc. The systems and methods disclosed herein can thus be provided as a singular unit configured to provide the various modules, display the various user interfaces, and capture the data described herein. The singular unit can be modular such that various aspects thereof can be swapped in and out as needed for, e.g., upgrade, replacement, maintenance, etc., without interrupting functionality of any other aspects of the system. The singular unit can thus also be scalable with the ability to be added to as additional modules and/or additional functionality of existing modules are desired and/or improved upon.
While some embodiments are described herein in the context of web pages, it will be appreciated that in other embodiments, one or more of the described functions can be performed without the use of web pages and/or by other than web browser software. A computer system can also include any of a variety of other software and/or hardware components, including for example, operating systems and database management systems. Although an exemplary computer system is depicted and described herein, it will be appreciated that this is for sake of generality and convenience. In other embodiments, the computer system may differ in architecture and operation from that shown and described here.
Referring again to the system 10 of
The accessory 12 can include an activation member 26, a sensor 28, an actuator 30, a network interface 32, a processor 34, and a power source 36. Each of the activation member 26, the sensor 28, the actuator 30, the network interface 32, the processor 34, and the power source 36 can have a variety of sizes, shapes, and configurations.
The activation member 26 can be configured to be activated by a user when medication is dispensed from the dispenser. The activation member 26 can be configured to be automatically activated when the medication is dispensed. In other words, the medication being dispensed in its ordinary way can activate the activation member 26 such that a user of the dispenser need not perform any special action to activate the activation member 26. The activation member 26 can thus be integrated into the functionality of the dispenser, which can help the accessory 12 gather data regarding the medication, as discussed further below. For example, the activation member 26 can be positioned at an end of a respiratory inhaler that, even without the accessory 12 attached thereto, is configured to be pushed down by a user to release a metered-dose of respiratory medication from the inhaler. The activation member 26 can thus be configured to move when the medication is dispensed, thereby activating the activation member 26.
The activation member 26 can include a depressible member, as in the illustrated embodiment. The depressible member 26 includes a button, e.g., a push button, in the illustrated embodiment, but the depressible member 26 can be in another form, such as a depressible switch. Pushing the accessory 12, e.g., pushing on an inhaler to release medication therefrom, can automatically activate the activation member 26 as well as cause the medication to be released.
An example of the activation member 26 not as a depressible member includes a motion-sensitive member such as a motion sensor configured to sense movement of the accessory 12. For example, the motion-sensitive member can be positioned at an end of a respiratory inhaler (e.g., an asthma inhaler) that, even without the accessory 12 attached thereto, is configured to be pushed down by a user to release a metered-dose of respiratory medication from the inhaler, such that the motion-sensitive member can sense movement when the accessory 12 is pushed down. For another example, a first motion-sensitive member can be positioned on an exterior plastic container of a respiratory inhaler (e.g., an asthma inhaler), and a second motion-sensitive member can be positioned on a medication canister that is at least partially encased by the exterior plastic container. A difference in motion detected by the two motion-sensitive members can indicate that medication was dispensed.
Referring again to
The pushing of the activation member 26 can be enough to cause the processor 34 to perform the function(s) related to dispensing of the medication. However, in some embodiments, the processor 34 can be configured to perform the function(s) related to dispensing of the medication in response to receipt of the activation signal only upon a secondary determination that medication was dispensed. In other words, the processor 34 can be configured to check for false positives. The sensor 28 can be configured to facilitate the secondary determination. The sensor 28 can help eliminate false positives when, for example, the dispenser is within a backpack or other bag and is jarred against a side of the bag so as to unintentionally, partially depress the activation member 26 and activate or “wake-up” the processor 34 even though medication was not actually dispensed.
The sensor 28 can have a variety of sizes, shapes, and configurations. The sensor 28 can be configured to sense at least one condition indicative of the medication being dispensed from the dispenser. The sensor 28 can be configured to transmit data regarding its sensed parameter(s) to the processor 34, which can be configured to analyze the received sensed data to help determine whether medication was dispensed from the dispenser. In general, the processor 34 can be configured to determine if the sensed parameter is above or below a predetermined threshold amount for the sensed parameter and conclude based on that determination whether the sensed parameter indicates that medication was dispensed.
The accessory 12 can include any number of sensors 28, e.g., zero, one, two, three, etc. If the accessory 12 includes a plurality of sensors 28, in an exemplary embodiment, each of the sensors 28 can be configured to sense a different parameter so as to provide a plurality of factors to aid in the processor's secondary determination of the medication being dispensed or not.
The sensor 28 can be configured to continuously sense data, or the sensor 28 can be configured to sporadically sense data based on activation of the activation member 26. The sensor 28 continuously sensing data can help ensure that the sensor 28 has adequate data available each time the processor 34 is activated by the activation member 26. Continually sensing data can help the processor 34 “learn” ambient conditions of the dispenser, the accessory 12, and/or the medication over time, which can help the processor 34 better distinguish false positives from actual instances of the medication being dispensed. The sensor 28 can be configured to sporadically sense data by being triggered by the processor 34 to begin sensing. The processor 34 can be configured to provide such a trigger when the processor 34 is activated by the activation member 26. Sporadically sensing data can consume less power than continuously sensing data, which can help prolong a life of the accessory 12.
Examples of the sensor 28 include a motion sensor, a pH sensor, a temperature sensor, an audio sensor, and a geographic location sensor. The motion sensor, e.g., an accelerometer, gyroscope, or a magnetic field sensor, can be configured to sense motion, e.g., movement, shock, vibration, orientation, etc., of the accessory 12. If the sensed motion is above a predetermined threshold amount of motion, the processor 34 can be configured to determine that medication was dispensed because the accessory 12 moved enough to cause the medication to be dispensed. The predetermined threshold amount of motion can vary based on the dispenser, as different dispensers can require a different amount of user-caused motion to dispense medication from the dispenser. If the motion sensor is configured to sense orientation, the processor 34 can be configured to determine whether the sensed orientation matches a predetermined orientation indicative of a medication-dispensing position of the dispenser. For example, respiratory inhalers are typically held in a same, upright position when medication is dispensed in order for the dispenser to be comfortably held by hand with the dispenser's output positioned adjacent the patient's mouth.
The pH sensor can be configured to sense a pH at a location where the medication is dispensed from the dispenser. For some types of medication, such as respiratory medications dispensed from an inhaler, the pH changes at an output of the dispenser because the medication has a different pH than ambient air ordinarily at the output. If the sensed pH is outside a predetermined temperature range, is above a predetermined threshold pH, and/or changes by more than a predetermined threshold amount, the processor 34 can be configured to determine that medication was dispensed because the pH changed enough to indicate that the medication was dispensed. The predetermined threshold pH and predetermined threshold amount can vary based on the medication, as different medications can have different pHs.
The temperature sensor can be configured to sense a change in temperature, such as a change in temperature of the dispenser. Some types of medication can cause the dispenser to temporarily change in temperature when the medication is dispensed from the dispenser. If the sensed temperature is outside a predetermined temperature range, is below a predetermined threshold temperature, and/or changes by more than a predetermined threshold amount, the processor 34 can be configured to determine that medication was dispensed because the temperature changed enough to indicate that the medication was dispensed. For example, at least some respiratory medications dispensed from an inhaler can cause the inhaler canister to temporarily decrease in temperature. The temperature sensor can thus facilitate determination that medication was dispensed from the canister. For another example, some medications can change temperature when damaged, e.g., decrease in temperature if left unrefrigerated beyond a certain amount of time. The temperature sensor can facilitate this determination of medication spoilage.
The audio sensor, e.g., a microphone, etc., can be configured to sense a sound of medication dispensing. Some types of medication can create a sound having a predictable profile when the medication is dispensed from the dispenser. If the sensed sound is within a certain decibel range and/or changes by more than a predetermined threshold amount, the processor 34 can be configured to determine that medication was dispensed because the sound matches a sound profile of the medication being dispensed. For example, at least some respiratory medications dispensed from an inhaler can cause a predictable misting sound at the dispenser's output that is not present unless the medication is being dispensed from the inhaler.
The geographic location sensor, e.g., a global positioning system (GPS) sensor, etc., can be configured to sense a geographic location of the patient. The accessory 12 can thus be configured to log a geographic location of the patient when medication is dispensed from the dispenser so as to help provide context for where a patient was when medication was taken. Such geographic data can help determine whether certain environments exacerbate a patient's condition, e.g., because more emergency doses of medication are taken when a patient is in a certain locale.
The actuator 30 can have a variety of sizes, shapes, and configurations. The actuator 30 can be configured to indicate to a user, e.g., to the patient 22, that a predetermined condition has occurred. The predetermined condition can reflect that action by the user is needed, such as the patient 22 taking a dose of the medication, the dispenser being replaced due to little medication remaining therein, or the dispenser being replaced due to no medication remaining therein. The predetermined condition can require no user action, such as a scheduled dose of the medication not being taken and data being transmitted from the accessory 12 to the wireless bridge 14. The processor 34 can be configured to actuate one or more of the actuators 30 in response to the processor 34 detecting occurrence of the predetermined condition, as discussed further below. Examples of the actuator 30 include a light (e.g., an LED, a fluorescent material, etc.) configured to illuminate, a speaker configured to output an audible sound, a vibration element configured to vibrate so as to cause palpable and/or audible vibration of the accessory 12 and/or the dispenser, a temperature-changing element configured to temporarily heat and/or cool so as to cause a palpable change in temperature of the accessory 12 and/or the dispenser, and a display screen configured to display text and/or images as a message to the user.
The accessory 12 can include any number of actuators 30, e.g., zero, one, two, three, etc. If the accessory 12 includes a plurality of actuators 30, in an exemplary embodiment, each of the actuators 30 can be configured to provide a different type of notification than at least one other of the actuators 30, e.g., a plurality of actuators 30 including at least one light and at least one speaker, so as to allow the accessory 12 to provide a plurality of different notifications when medication is due and/or to provide a different type of notification upon different types of predetermined conditions, a light of a first color and one vibration element for medication being due, a light of a second color for medication in the dispenser running low and a blinking light of the second color for medication in the dispenser being depleted, a blinking light when a medication dose is missed and a notification such as an email, text message, or phone call (which can be a live phone call or an automated phone call and can include leaving a voicemail or other recorded message) being sent to a location remote from the dispenser indicating that the medication dose was missed, etc.
The accessory 12 can be configured to cause a notification to be transmitted to a location remote from the dispenser instead of or in addition to a notification being provided via the actuator 30 at the dispenser. Providing a remote notification can facilitate supervision of the patient 22 and/or management of the patient's treatment plan. For example, if the patient 22 is a child, it can be beneficial to notify the user 24 associated with the patient upon occurrence of certain events to help make the user 24 aware of the patient's medication status so the user 24 can take any appropriate action in real time and/or at a later time. For example, if a dose of medication is due, the processor 34 can be configured to cause a first notification to be provided to the patient 22 via the actuator 30 at the dispenser and to cause a second notification to be provided to the user 24, who may be at a location remote from the patient 22. The user 24 can then decide whether to independently contact the patient 22 as a secondary reminder to take medication. For another example, if the processor 34 determines that medication was dispensed off the patient's predetermined medication schedule, the processor 34 can be configured to cause a notification such as an email, text message, or phone call to be provided to the user 24, who, given this atypical use of the medication, may be the patient's medical care provider or be able to contact the patient's medical care provider as the patient's parent or guardian. If multiple off-schedule medication doses are detected, the patient's medical care provider may choose to contact the patient 22 (or an adult contact for a child patient) to discuss possible changes to the patient's health and/or to the patient's treatment plan. For another example, if medication is not dispensed within a predetermined period of time after a notification is provided indicating that a scheduled dose of medication is due, the processor 34 can be configured to cause a missed dosage notation to be saved in the accessory's memory, and the wireless bridge 14 can be configured to wirelessly transmit the stored missed dosage notation to an external device such as the database 18. The missed dosage notation can be included as part of adherence data and/or incentives data provided on a user interface, discussed further below. An external device, e.g., the interface 20, can be configured to determine that a medication dose was missed without the processor 34 providing any notice thereof, such as by the external device being configured to detect that notice of an expected dose was not taken, e.g., notice of medication being dispensed at a scheduled date/time was not received at the external device from the accessory 20. For yet another example, if the processor 34 determines that the medication is running low, the processor 34 can be configured to cause a notification such as an email, text message, or phone call to be provided to the user 24, such as the patient's doctor or pharmacist, who can begin processing a new supply of medication for the patient 22 before the patient's current medication is depleted.
The processor 34 can be configured to control one or more components of the accessory 12. The processor 34 can have a variety of sizes, shapes, and configurations, as discussed above. The processor 34 in the illustrated embodiment is shown as a microcontroller, but the processor 34 can include any of a variety of elements, as mentioned above. The processor 34 can, as will be appreciated by a person skilled in the art, include a timer configured to count time and/or a memory configured to store data. Alternatively, the timer and/or the memory can be included as part of the accessory 12 but be external components to the processor 34.
The processor 34 can be configured to cause gathered data to be stored in the memory and to cause stored data to be transmitted to an external device, e.g., wirelessly transmitted via the wireless bridge 14 across the network 16 to the interface 20 and/or the memory 18. The memory 18 in the illustrated embodiment includes a database, but as discussed above, the memory 18 can include any one or more memory technologies. The interface 20 in the illustrated embodiment includes a client station in the form of a distributed computer system (e.g., a phone, a computer, etc.), but the interface 20 can include any form of client station.
The processor 34 can be configured to transmit stored data to the interface 20 and/or the memory 18 on a predetermined transmission schedule, e.g., a schedule stored in the memory and time-tracked using the timer, in response to occurrence of a predetermined condition, and/or in response to a data request signal to the processor 34 from an external device. The processor 34 can be configured to delete transmitted data from the memory in response to the data having been transmitted, which can help free space for new data, the processor 34 can be configured to delete transmitted data on a regular deletion schedule (e.g., at the top of each hour, at the end of a day, at the end of a week, twice daily, etc.), or the processor 34 can be configured to delete transmitted data as needed for storage space. The processor 34 can be configured to maintain all data until the data is transmitted to an external device, which can help prevent data loss. The processor 34 can be configured to mark data stored in the memory as having been transmitted to an external device, which can facilitate clearing of the accessory's memory and/or help ensure that data is not unnecessarily repeatedly transmitted to an external device.
Various types of data can be received and stored by the processor 34. For example, data sensed by the sensor 28 can be received and stored. For another example, data regarding occurrences of predetermined conditions can be stored. Examples of predetermined conditions include medication being dispensed (e.g., as triggered by activation of the activation mechanism 26 and/or as confirmed by data from the sensor 28), low power source 36 power, power source 36 depletion, medication not being dispensed in accordance with a predetermined medication schedule, and device component failure. The processor 34 can therefore be configured to receive, store, and transmit a relatively complete picture of the patient's medication usage and of a functional status of the dispenser and a functional status of the accessory 12. Data transmitted by the processor 34 can be analyzed by and/or viewed on the interface 20, as discussed further below.
The processor 34 can be configured to maintain a running tally of a total amount of medication dispensed from the dispenser. In this way, the processor 34 can be configured to determine when the dispenser is running low on medication and/or when all medication has been dispensed from the dispenser. For example, some types of dispensers, such as respiratory inhalers, can be configured to dispense a predetermined amount of medication each time the medication is dispensed therefrom. The processor 34 can be configured to maintain the running tally of a total amount of medication dispensed from the dispenser by adding a predetermined value to the previously logged total amount each time medication is determined to have been dispensed from the dispenser. For another example, the accessory 12 can be configured to detect an amount of medication dispensed, e.g., by using the sensor 28, and to subtract the measured amount from a previously stored total amount of medication in the dispenser to arrive at a current total amount of medication in the dispenser.
The processor 34 can be configured to provide a warning to a user when the processor determines that the dispenser is running low on medication and/or when all medication has been dispensed from the dispenser. Providing warnings about low/no medication remaining can help the user effectively manage reordering and replacement of medication. The processor 34 can be configured to provide the warning by actuating the actuator 30.
The processor 34 can be configured to actuate the actuator 30 by transmitting a signal thereto. In response to the triggering signal from the processor 34, the actuator 30 can be configured to provide an audible and/or palpable signal to a user, e.g., to the patient 22, indicating one or more predetermined conditions. One example of the predetermined condition is the low medication warning mentioned above, and another example of the predetermined condition is the medication depleted warning also mentioned above.
Another example of the predetermined condition is a notification when a dosage of the medication is due. In other words, the accessory 12 can be configured to provide notice to a user, e.g., to the patient 22, that medication needs to be taken in order to adhere to a predetermined medication schedule. The accessory 12 providing the notification can allow the medication dispenser itself to play a role in a patient's medication regimen, which can help reduce the need for the patient, the patient's family, the patient's doctor, etc. to maintain and monitor an external notification system, such as watch alarms, alarms on a mobile device, phone calls to the patient, text messages to the patient's mobile phone, etc.
The processor 34 can be configured to determine that a dosage of medication is due in a variety of ways. A predetermined medication schedule for the patient 22 can be accessible to the processor 34, e.g., stored in a memory included in the accessory 12 or stored in an external memory accessible via the network 16, such as the memory 18. The predetermined medication schedule can, as will be appreciated by a person skilled in the art, be specific to the patient 22 as determined by the patient's doctor or other care provider, or the predetermined medication schedule can be dictated by a manufacturer of the medication. The accessory 12 can be configured to register itself, e.g., with the memory 18, when purchased and/or when attached to a medication dispenser so as allow the predetermined medication schedule to be transmitted to the accessory 12, e.g., from the memory 18. The processor 34 can be configured to determine when medication is due according to the predetermined medication schedule based on time counted by the timer. The accessory 12 can thus be configured as a self-contained monitoring unit able to notify the user that medication is due to be taken regardless of the accessory's location relative to the interface 20 and/or other external device. Alternatively, or in addition, an external device such as the interface 20 can be configured to determine when a dosage of the medication is due for the patient 22 in a similar way and transmit a signal to the accessory 12 via the network 16. The signal can cause the actuator 30 to be actuated. Allowing the external device to trigger the actuator 30 can provide backup functionality to the processor 34 and/or can help move processing resources off-board from the accessory 12, which can help reduce cost and/or help reduce a size of the accessory 12.
Another example of a predetermined condition is data being transmitted from the accessory 12 via the network interface 32. Providing notice to the user that data is being transmitted can help explain why the accessory 12 may be buzzing or otherwise making a noise not typically associated with the medication dispenser. Similarly, another predetermined condition is data being transmitted to the accessory 12 via the network interface 32, such as an update to the patient's predetermined medication schedule stored onboard the accessory 12.
As mentioned above, a predetermined condition can include the power source 36 running low, thereby indicating that the accessory 12 is due for removal from the dispenser and replacement with another accessory. Similarly, another predetermined condition is the power source 36 being depleted of available power.
As mentioned above, a predetermined condition can include failure of any component of the accessory 12, such as a failure of the sensor 28 or the actuator 30, thereby indicating that the accessory 12 should be removed from the dispenser and replaced with another accessory. The processor 34 can be configured to detect failure of a component of the accessory 12, such as by being programmed to regularly query component(s), as will be appreciated by a person skilled in the art, and, based on a response received from the queried component, including whether a response was received or not, determine whether the component is properly functioning.
The network interface 32 can be configured to facilitate electronic communication of the accessory 12 with one or more external devices such as the wireless bridge 14. The network interface 32 can have a variety of sizes, shapes, and configurations, as discussed above. Although the network interface 32 is illustrated as a radio and as being in electronic communication with the wireless bridge 14 in the illustrated embodiment, the network interface 32 can be a component other than a radio and can be configured to be in electronic communication with a wireless bridge and/or any number of other components to facilitate communication over the network 16. The network interface 32 can be configured to communicate using long-range, low frequency/low power/low bandwidth radio communication using a proprietary, an open source, or a mesh protocol.
The power source 36, e.g., one or more batteries, one or more solar panels, one or more piezo elements, one or more inductively charged power elements, etc., can have a variety of sizes, shapes, and configurations. The power source 36 can be configured to provide power to one or more of the accessory's components, e.g., to the sensor 28, the processor 34, the wireless bridge 14, the actuator 30, etc. In some embodiments, an accessory can lack a power source and instead be powered by an external power source, such as a power source wired to the accessory via wired connection or a power source configured to telemetrically provide power when moved into proximity of the accessory. In some embodiments, an accessory can include an on-board power source, as in the illustrated embodiment of
The power source 36 can be configured to move between a first state in which the power source 36 provides a first amount of power to components of the accessory 12 and a second state in which the power source provides a second, greater amount of power to the components of the accessory 12. The power source 36 can thus be configured to conserve power by being in the first state when the greater amount of power provided in the second state is not necessary for proper functioning of the accessory 12.
In an exemplary embodiment, the power source 36 in the first state can be configured to provide a non-zero amount of power to the processor 34 and in the second state can provide a greater amount of power to the processor 34. The non-zero amount of power can be an amount of power adequate to power the processor's timer, thereby allowing the timer to maintain accurate time so as to, e.g., allow notifications to be properly triggered for due medication doses, allow for a correct date/time to be logged upon detection of medication being dispensed from the dispenser, etc. If the timer is a separate component from the processor 34, the power source 34 in the first state can be configured to provide the non-zero amount of power to the timer instead of to the processor 34.
The non-zero amount of power can be less than a required amount of power to allow data to be stored in the accessory's memory, while the amount of power provided when the power source 36 in the second state can be enough to allow the processor 34 to store data in the memory. The power source 36 can thus conserve power by not providing power to the processor 34 for memory storage unless the processor 34 receives data to store in the memory. The power source 36 can be configured to move from the first state to the second state in response to the sensor 28 sensing the medication being dispensed, thereby allowing the processor 34 to have adequate power to receive and store the sensed data in the memory. The power source 36 can be configured to move from the second state to the first state in response to storage of the data in the memory, thereby allowing the power source 36 to return to the lower power supply state when the processor 34 no longer needs the higher amount of power to store data.
In the first state, the power source 36 can be configured to provide no power to components of the accessory 12 other than the processor 34 (or the timer), which can help conserve power. In the second state, the power source 36 can be configured to provide power to one or more components of the accessory 12 in addition to the processor 34 (or the timer), which can allow the processor's commands to be carried out, e.g., for the actuator 30 to be actuated, for the wireless bridge 14 to transmit data, etc. The power source 36 can thus be configured to continuously provide power to the processor 34 (or the timer) and only intermittently provide power to the accessory's other components. For example, the power source 36 can be configured to only provide power to the actuator 30 when the power source 36 is in the second state so as to allow the actuator 30 to provide a notification in response to a determination that a scheduled medication dose is due. For another example, the power source 36 in the first state can be configured to not provide adequate power to the wireless bridge 14 to allow the wireless bridge 14 to wirelessly transmit data, and the power source 36 in the second state can be configured to provide adequate power to the wireless bridge 14 to allow the wireless bridge 14 to wirelessly transmit data. The wireless bridge 14 can thus only receive power when data is available for transmission to an external device such as the database 18 or the interface 20. The power source 36 in the second state can be configured to provide all power for the wireless transmission by the wireless bridge 14. The power source 36 can be configured to move from the first state to a third state in response to a request for data from an external device such as the database 18 or the interface 20. The power source 36 in the third state can be configured to provide adequate power to the wireless bridge 14 to allow the wireless bridge 14 to wirelessly transmit data to the external device in response to the request for data, and the power source 36 can be configured to move from the third state to the first state in response to the wireless bridge 14 wirelessly transmitting data to the external device in response to the request for data. The wireless bridge 14 can thus only receive power when needed in order to fulfill an external request for data.
If the sensor 28 requires power to sense data and does not include its own onboard power, the power source 36 in the first state can be configured to provide a non-zero amount of power to the sensor 28 so as to allow the sensor 28 to continuously sense data to facilitate determination of medication being dispensed from the dispenser. In the second state, the power source 36 can continue to provide the non-zero amount of power to the sensor 28.
The accessory 12 can include a housing 42 configured to house the activation member 26, the sensor 28, the actuator 30, the network interface 32, the processor 34, the power source 36, and the wireless bridge 14. The accessory 12 as a singular unit including the housing 42 and all components housed therein can be configured to be removably and replaceably attached to the medication dispenser, thereby allowing simple attachment of a single piece to the medication dispenser to attach the accessory 12 thereto. The accessory 12 can thus lack any required user assembly and be easily attached to a medication dispenser by adults and by at least older children.
The housing 42 can have a variety of sizes, shapes, and configurations and can be formed from one or more materials. In an exemplary embodiment, the housing 42 can be formed from one or more polymers and can be non-toxic. The housing 42 can be rigid or, as in the illustrated embodiment, have some degree of flexibility, which can facilitate depression of the activation member 26, as discussed further below. The housing 42 can be transparent or translucent so as to allow a light to visibly shine therethrough, as also discussed further below. The housing 42 can be waterproof so as to help protect the various components housed therein from moisture damage. The housing 42 can be permanently closed or sealed (e.g., closed or sealed under conditions of ordinary end-user use) so as to help prevent tampering with and/or inadvertent damage to the various components housed therein. The housing 42, and hence the accessory 12, can be configured to be disposable, e.g., thrown out or recycled. An accessory can, in some embodiments, be nonremovably attached to a medication dispenser, in which case the accessory can be configured to be disposed of with the medication dispenser.
The housing 42 is shown in the illustrated embodiment as housing all of the activation member 26, the sensor 28, the actuator 30, the network interface 32, the processor 34, the power source 36, and the wireless bridge 14, but one or more of these components can be disposed in at least one other housing configured to attach to the medication dispenser similar to that discussed herein regarding the housing 42. For example, the wireless bridge 14 can be housed in a second housing (not shown) of the accessory 12, which can help facilitate hardware and/or software repair and/or upgrades related to electronic communication that otherwise do not substantially affect operation of the accessory 12. The second housing can be made, configured, and used similar to that discussed herein regarding the housing 42.
The accessory 12 can be configured to be attached to the dispenser in a variety of ways. The accessory 12 can include an attachment mechanism configured to engage the dispenser and removably and replaceably attach the accessory 12 thereto. Examples of the attachment mechanism include a magnet configured to magnetically attach the accessory 12 to a magnet included in or a metallic material of the dispenser, Velcro®, a cavity formed in the accessory configured to fit around a portion of the dispenser in a press fit, a strap or band configured to be tied to secure the accessory 12 to the dispenser, a strap or band configured to elastically secure the accessory 12 to the dispenser similar to a rubber band, a clip configured to clip the accessory 12 to the dispenser, and a guide track configured to slidably receive a portion of the dispenser therein. The attachment mechanism as a magnet can be particularly effective for use with pressurized medication dispensers, such as respiratory inhalers, which are typically metallic containers. The attachment mechanism being attachable to the dispenser by press fit can help prevent mis-attachment of the accessory 12 to the dispenser because the cavity can be configured to be attachable to the dispenser in one location via the press fit, e.g., the cavity being configured to only accommodate one unique portion of the dispenser. The accessory 12 can be included as part of a kit including a plurality of differently sized and/or differently shaped members (e.g., flexible rings, rigid rings, etc.) configured to be selectively attached to the accessory 12 to facilitate press fit of the accessory 12 to a particular medication dispenser. For example, a one of the members having a size and shape corresponding to a circular size of an end of a respiratory inhaler can be inserted into a cavity of an accessory in the form of a cap so as to be seated in a groove formed therein. The member can be configured to form a press fit with the inhaler when the cap is attached thereto. The attachment mechanism being an adjustable member, such as a strap or band, can facilitate attachment of the accessory 12 to differently sized and/or irregularly shaped dispensers.
The attachment mechanism can allow the accessory 12 to be replaceably and removably attached to the dispenser without requiring any modification of the dispenser by the end-user or by a designer or manufacturer of the dispenser to accommodate the accessory 12. In this way, the accessory 12 can be used with nearly any medication dispenser regardless of whether or not the dispenser was made for use with the accessory 12. Examples of attachment mechanisms that can allow for such attachment include a magnet, a cavity, and a strap or band. Other attachment mechanisms, such as a magnet or Velcro®, may require a modification of the dispenser to allow attachment of the accessory 12 thereto, such as by attaching a magnet or Velcro® to the dispenser using a self-stick adhesive.
The housing 300 can be a cap, as in the illustrated embodiment of
In the illustrated embodiment, the attachment mechanism of the accessory 302 includes a cavity 308 formed in the housing 300. The cavity 308 can be configured to receive a portion of the dispenser 304 therein, e.g., an end portion of the dispenser 304. In the illustrated embodiment, the cavity 308 is configured to only be attachable to that one portion of the dispenser 304, which as mentioned above, can help ensure that the accessory 302 is properly attached to and used with the dispenser 304 because there is only one option to the user in choosing where to attach the accessory 302 to the dispenser 304.
The housing 300 can include a symbol 310 thereon, e.g., printed thereon, formed therein as a depression (as in the illustrated embodiment), formed thereon as a protrusion, embedded therein, etc. The symbol 310 can include any one or more of numbers, alphabet characters, and geometric shapes, logos, and other symbols. Although only one symbol 310 is shown in the illustrated embodiment, a housing can include any number of symbols thereon. The symbol 310 can identify a manufacturer of the accessory 12, can identify a specific medication or type of medications for use with the accessory 12, and/or can be decorative (e.g., a patient's name, a patient's first initial, a cartoon character, etc.). In the illustrated embodiment, the symbol 310 includes a plus sign.
As shown in
The activation member 606 can be configured to move within the accessory 600 relative to the PCB 608 in response to a user, e.g., a patient, pushing or pressing on the housing 602, e.g., pushing or pressing on a proximal surface 624 of the housing 602. The user pushing or pressing the housing 602 can thus push or press the button 606, e.g., move the activation member 606 in a distal direction, so as to move the button from a non-depressed position to a depressed position. The activation member 606 moving relative to the PCB 608 can cause the activation member 606 to contact the PCB 608 so as to cause a circuit thereof to close. As discussed above, closing the circuit can cause the accessory's processor to be activated. The activation member 606 can be configured to automatically move from the depressed position to the non-depressed position in response to the user removing the pushing or pressing force on the housing 602.
The symbol 604 can be formed on the housing 602 adjacent to the activation member 606 disposed therein, e.g., positioned directly proximally above the activation member 606, which can facilitate user activation of the activation member. The symbol 604 can include instructional text such as “push here” or “press” to help a user properly use the accessory 600 and activate the activation member 606. Additionally or alternatively, written and/or audible instructions provided with the accessory 600 can instruct a user to push or press on the symbol 604 to dispense medication from the dispenser after the accessory 600 has been attached to the dispenser.
A void space 622 can exist between the button 606 and the housing 602 when the button 606 is in a non-depressed position, as in
The housing 702 can have a variety of sizes. In the illustrated embodiment, the housing 702, and hence the cap 700, has a height 702H of 0.7 in. and a width 702W of 1 in, which can facilitate attachment of the cap 700 to an end of a standard sized respiratory inhaler.
As shown in
Referring again to
The wireless bridge 800 can include an attachment mechanism similar to that discussed above to facilitate removable and replaceable attachment of the dispenser 724. As in the illustrated embodiment, the wireless bridge 800 can include an attachment mechanism in the form of a cavity 812 formed therein to fit around a portion of the dispenser 724 in a press fit.
The wireless bridge 800 can include a housing 802, a wireless module 804, a CCS module 806, a power source 808 (in the form of a battery pack in this illustrated embodiment), and a power board 810. The housing 802 can, as in the illustrated embodiment, be configured to house the CCS module 806, the power source 808, and the power board 810 therein.
The connector port 912 can allow the wireless bridge 900 to communicate via a wired connection, e.g., via an Ethernet cable, in addition to or in alternative to communicating wirelessly using the wireless module 904. Transmitting and receiving data via a wired connection can facilitate communication between the accessory and any external device and/or can facilitate on-demand transmission of data to the accessory and/or on-demand receipt of data from the accessory.
The power jack 914 can allow for external power to be provided to the wireless bridge 900, which can help conserve power of the on-board power source 906 and/or allow for communication of data from the wireless bridge 900 even if the power source 906 has been drained of power.
The power on/off element 916 can allow the power source 906 to be selectively turned on and off. This on/off capability can help conserve power, thereby prolonging the life of the power source 906 and hence of the wireless bridge 900. The power indicator 918 can be configured to visually indicate the on/off status, e.g., by illuminating when the element 916 is in the “on” position and by not being illuminated when the element 916 is in the “off” position.
As mentioned above, any of a variety of users can access, interact with, control, etc. a user interface, with the user interface optionally being customized for a category of a particular user, such as any one or more of a relationship of the user to the patient (e.g., the patient, a family member of the patient, a care provider for the patient, etc.), a gender of the user, and an age of the user. The user interface can provide data regarding any one or more aspects of a system including an accessory, medication associated with the accessory, and a patient associated with the medication. In addition to providing data to a user, the user interface can be configured to accept user input, e.g., via an I/O device, and data input by the user can be stored in any one or more memories. For example, the user interface can be configured to prompt a user to enter data in response to a question regarding medication administration that can help explain any anomalies, e.g., a question asking what the patient was doing or experiencing when emergency medication was administered (e.g., playing sports, sleeping, attending school class, suffering from allergies, etc.), etc., a question asking why a medication dosage was missed, etc. An accessory's processor and/or a processor located remotely from the accessory can be configured to analyze input answers so as to “learn” patient behavior and incorporate the “learned” behavior into, e.g., recommendations regarding the patient's treatment plan and predictions of the patient's future behavior.
The user interface can be configured to display an avatar for a user. The avatar can allow a user to be able to quickly and easily determine that they are viewing the correct page by seeing their avatar. The avatar can give the user interface a more personal feel, which can make the user interface more fun to use and thus more likely to be used, particularly by children. The avatar can be customizable by a user, as will be appreciated by a person skilled in the art.
Each of the user interfaces 1100, 1102, 1104 show symbolic representations of examples of different types of information that can be shown on a user interface. The embodiments of information types shown in the illustrated embodiment include medication dose notification data 1112 indicating that a medication dose is due for a patient according to the patient's predetermined medication schedule, incentive data 1114 indicating progress toward and/or achievement of one or more medication adherence goals, adherence data 1116 indicating adherence to one or more predetermined medication schedules, and patient treatment data 1118 indicating one or more patient treatment plans. Other examples of information types include accessory status data indicating status of an accessory, medication status data indicating status of medication in a medication dispenser, and prediction data indicating one or more predictions of a patient's future behavior based on the patient's historical adherence data. Any of the information types can be displayed using text and/or graphics. The information shown on the first, second, and third user interfaces 1100, 1102, 1104 can be provided over a network 1120, such as a cloud having access to information 1122, e.g., access to a database storing the information 1122, that can be provided to the client terminals 1106, 1108, 1110. Although certain types of information are shown on each of the user interfaces 1100, 1102, 1104, and in the cloud 1122, any type of information and any combination of information types can be shown on a user interface of any client terminal, subject to any user restrictions such as not allowing non-clinician users to view information regarding patients other than a specific patient authorized for a particular non-clinician user, and subject to any client terminal limitations such as a client terminal not being configured to show data having a certain file extension.
The system 1000 can include an accessory data input module 1002, a remote data input module 1004, an adherence module 1006, and a medication module 1008, and an incentives module 1010. Any of the accessory data input module 1002, the remote data input module 1004, the adherence module 1006, and the medication module 1008, and the incentives module 1010 can be used independently from one another and can be used in combination with any one or more of the other modules 1002, 1004, 1006, 1008, 1010. Each of the modules 1002, 1004, 1006, 1008, 1010 is discussed further below in turn. Although each of the modules 2001002, 1004, 1006, 1008, 1010 is illustrated in
The system 1000 can also include an accessory data database 1012 and a remote data database 1014. The accessory data database 1012 can be configured to be accessible by the accessory data input module 1002 and to store data regarding a mechanical accessory. The remote data database 1014 can be configured to be accessible by the remote data input module 1004 and to store data regarding patients in a patient database 1016 and data regarding incentives in an incentives database 1018. Each of the databases 1012, 1014 is discussed further below in turn with respect to various modules 1002, 1004, 1006, 1008, 1010. Each of the databases 1012, 1014 can include any number of component databases, e.g., one, two, three, etc., the same or different from any of the other databases 1012, 1014. As mentioned above, a person skilled in the art will appreciate that any of the databases 1012, 1014, and any of their various component databases (if any), can be subdivided or can be combined with other databases, including databases illustrated in
Generally, as illustrated in
The accessory data input module 1002 can generally allow an accessory to input data regarding the accessory to the system 1000. The submitted accessory data can then be used by the adherence module 1006, the medication module 1008, and/or the incentives module 1010 to perform various analyses 1024 that can result in output(s) to a user via the user interface, as discussed further below. The user interface configured to allow users to access data can have a variety of configurations. The user interface can be configured to be displayed on a client terminal.
As mentioned above, the accessory data input module 1002 can be configured to read information from and/or write information to the accessory data database 1012. Thus, the accessory data input module 1002 can be configured to write submitted accessory data to the accessory data database 1012. The accessory data can be organized in any way in the accessory data database 1012 and/or in one or more other memories accessible by the system 1000. In an exemplary embodiment, accessory data can be stored in a table in the accessory data database 1012 such that each accessory has his/her own row or column of data populated with data related to that accessory. However, as will be appreciated by a person skilled in the art, accessory data can be stored in any way.
The accessory data input module 1002 can be configured to automatically gather accessory data, e.g., according to a schedule programmed into a client terminal able to access the system 1000, and/or can be configured to passively receive accessory data as transmitted by an accessory, e.g., according to a schedule programmed into the accessory. In an exemplary embodiment, the accessory data input module 1002 can be configured to automatically gather data and to passively receive accessory data, thereby maximizing an amount of data that the system 1000 can consider in performing various analyses 1024.
The accessory data input module 1002 can be configured to receive a variety of different types of data regarding an accessory. The accessory data include any type of data configured to be gathered, sensed, and/or analyzed by an accessory, as discussed above. Examples of accessory data include data regarding medication that was dispensed from the accessory (e.g., a date the medication was dispensed, time the medication was dispensed, an amount of medication dispensed at a particular date/time, whether medication was dispensed at a date/time consistent with the patient's predetermined medication schedule, etc.), failure data regarding any of the accessory's components, low or depleted power source data, data regarding a dosage not dispensed as prescribed in a predetermined medication schedule, identification information (e.g., a serial number of the accessory, an identification code for the patient associated with the accessory, etc.), etc.
The remote data input module 1004 can generally allow patient data and incentives data to be input to the system 1000 and stored remotely from accessor(y/ies) associated therewith. The submitted patient data and/or the incentives data can then be used by the adherence module 1006, the medication module 1008, and/or the incentives module 1010 to perform various analyses 1024 that can result in output(s) to a user via the user interface, as discussed further below.
As mentioned above, the remote data input module 1004 can be configured to read information from and/or write information to the remote data database 1014. Thus, the remote data input module 1004 can be configured to write submitted data to the remote data database 1014. The data can be organized in any way in the remote data database 1012 and/or in one or more other memories accessible by the system 1000. In an exemplary embodiment, patient data can be stored in a table in the patient data database 1016 such that each patient has his/her own row or column of data populated with data related to that patient, and general incentives data can be stored in the incentives database 1018. However, as will be appreciated by a person skilled in the art, remote data can be stored in any way. The remote data input module 1004 can be configured to automatically gather and/or can be configured to passively receive data, similar to that discussed above regarding the accessory data input module 1002.
The remote data input module 1004 can be configured to receive a variety of different types of data, such as patient data and incentives data. Examples of patient data include identification information for the patient (e.g., medical record number, name, etc.), care provider data for the patient (e.g., the patient's primary care physician, any specialist(s) who have treated the patient, etc.), clinical trial data for a clinical trial involving the medication and the patient, medication data (e.g., types of medication prescribed to the patient, predetermined medication schedules for medication being taken by the patient, any patient allergies, etc.), and medical history data for the patient. Examples of incentives data include patient goal data (e.g., benchmarks to achieve rewards, etc.), goal progress data (e.g., progress toward the benchmarks, etc.), rewards data (e.g., available virtual and/or physical rewards for achieving a benchmark, etc.), and historical goal data (e.g., goals previously reaches, time periods needed to achieve benchmarks, etc.).
The adherence module 1006 can generally provide users of the system 1000 with a user interface for receiving one or more reports regarding one or more patients' adherence to the patients' individual predetermined medication schedules. The adherence module 1006 can be configured to provide a user of the system 1000 with at least one textual and/or graphic report indicating a selected patient's adherence to a predetermined medication schedule for a medication dispensable from a dispenser having an accessory attached thereto. The adherence report(s) can facilitate evaluation of the patient's use of the medication, of the patient's predetermined medication schedule, and/or of the patient's overall treatment plan.
The adherence module 1006 can be configured to provide a user of the system 1000 with textual and/or graphical adherence data indicating a plurality of patients' adherence to the patients' individual predetermined medication schedules for a certain type of medication. The adherence data can facilitate an overall evaluation of how easily or difficult patients find adhering to schedules for this medication and/or a comparison of a particular patient's adherence with other patients taking the same medication. The adherence data can thus help a care provider adjust one or more patients' treatment plans by, e.g., changing to a different medication and/or adjust the predetermined medication schedules.
The adherence data can be shown for a patient over a predetermined time period, e.g., a time period previously set as a default for a particular user or a single available time period. The predetermined period can be adjustable, such as by allowing a user to select a time period. Examples of time periods include time elapsed for the current date, 24 hours, one month, one week, two weeks, three days, etc. In general, the longer the time period, the easier it can be to determine a patient's pattern of adherence.
Each of the time periods can cause a different set of data to be displayed. For example, a time period of less than one week can show complete adherence data for each day in the time period, while a time period of one week or greater can show only selected adherence data in order to allow all the days in the time period to be simultaneously shown on a limited amount of screen space.
The adherence data can include information regarding a patient's compliance with the patient's predetermined medication schedule, such as whether the patient took a required medication dose at the required day/time. As will be appreciated by a person skilled in the art, a patient can be considered to have taken medication on schedule even if not precisely at the required date/time. An acceptable amount of time deviation from a required time for a medication dose can be preprogrammed into the system. The acceptable amount of deviation can vary based on, e.g., a type of the medication. Other information regarding the patient's compliance with the patient's predetermined medication schedule can include information regarding any off-schedule medication doses administered to the patient. Such off-schedule administration can indicate emergency use of the medication or of a different medication to treat immediate symptoms, such as a rescue use of an inhaler to treat an asthma attack.
In one embodiment, the user interface can show adherence data for a single medication being taken by a single patient. The user interface can thus provide focused information regarding the patient and the medication, which can help highlight any anomalies regarding this particular medication for this patient. In another embodiment, the user interface can show adherence data for a plurality of medications being taken by a single patient. The user interface can thus provide a medication overview for the patient, which can help in evaluating a patient's overall treatment plan. In yet another embodiment, the user interface can show adherence data for a single medication being taken by a plurality of patients. The user interface can thus help highlight any anomalies regarding this particular medication for a patient population. In another embodiment, the user interface can show adherence data for a plurality of medications each being taken by a plurality of patients. The user interface can thus facilitate evaluation of a treatment plan for a particular ailment that involves prescribing the plurality of medications.
The user interface can be configured to show different adherence data for different users, e.g., show only graphical adherence data to patients under a certain age; show different, more complicated graphics or icons to adults than to children; show prescription data only to clinicians; provide different tips for improving adherence to family members of a patient than to the patient; ask different questions regarding adherence to family members of a patient than to the patient (e.g., ask a family member if they were present or not for a scheduled but missed medication dose, ask a patient why a dose was missed, ask a patient if a dose that was taken was scheduled at an inconvenient day/time, etc.); etc.
The adherence module 1006 can be configured to determine predictions of a patient's future behavior based on the patient's historical adherence data. The adherence module 1006 can be configured to access the patient's historical adherence data, e.g., from the database 18, and analyze 1024 the patient's historical adherence data to make one or more predictions of future behavior. Examples of predicted future behavior include a prediction of changes in the patient's health based on the patient's compliance (e.g., the patient's condition being predicted to deteriorate at a certain rate if medication doses keep being missed at the rate detected for the previous month or other previous time period, the patient's condition being predicted to improve based on the patient's steadily decreasing number of emergency medication doses, etc.), a prediction of the patient's future adherence to the patient's predetermined medication schedule based on the patient's compliance (e.g., predicting the patient to comply less with the schedule in the following month than in the preceding month based on multiple previous consecutive months of continuously reduced compliance, etc.), and a comparison of the patient's compliance with a plurality of other patients' compliance with their respective predetermined medication schedules (e.g., the patient being below average compliance, the patient being above average compliance, etc.).
The user interface 1200 can provide an overall rating for each of the days 1202, 1204, 1206, 1208, such as by showing a success icon (only shown for two days 1204, 1206 in
Although not shown in
The adherence information in a multi-day view, such as this monthly view, can include one or more total counts for various adherence data. Examples of total counts include a total count of taken scheduled doses for the days in the current view, a total count of unscheduled medication doses for the days in the current view, a total count of missed scheduled dose for the days in the current view, a total count of days in the current view in which all scheduled medication doses were taken and no unscheduled doses were taken (so-called “perfect days”), a total count for each possible overall rating, etc.
One of the user interfaces 1400 shows a graphical summary 1406 of medication dosages taken during the month, each day of the month being plotted on the graph. The graphical summary 1406 also indicates, via alert symbol 1408, each day in which an unscheduled medication dose was dispensed. The other of the user interfaces 1500 shows a summary of medication dosages taken during the month in a different way than the user interface 1400. The user interface 1500 shows total counts for various activities in the month (e.g., 17 medication doses taken on schedule, 63 medication doses taken off but near schedule, 10 missed scheduled medication doses, 2 emergency medication doses, and 7 “perfect days”). The user interface 1500 also shows an overall rating for the month, in the form of a smiling/frowning face, and an overall percentage for the month. By showing both scheduled medication doses taken and unscheduled medication doses taken, the user interfaces 1400, 1500 can facilitate understanding by patients, patient family members, doctors, etc. that as adherence decreases, e.g., as patients miss more scheduled medication doses, unscheduled medication use increases.
The medication module 1008 can generally provide users of the system 1000 with a user interface for receiving one or more textual and/or graphic reports regarding one or more patients' medication. The medication report(s) can facilitate evaluation of the currently prescribed type and amount of medication as an effective treatment for the patient.
The medication report(s) can provide one or more recommended changes to a patient's predetermined medication schedule, such as a shift of all medication doses one hour earlier if the patient is consistently missing the last scheduled dose of the day, shifting days of medication being due to only weekdays since weekend medication doses are being consistently missed, etc. The report(s) can provide one or more recommended changes to how soon before a dose is due are medication dose notifications provided to the patient by an accessory attached to a medication dispenser, such as five minutes before a dose is due instead of one minute because doses are being consistently taken a few minutes late, providing multiple notifications for each scheduled dose (e.g., notifications being provided ten minutes before doses are due in addition to five minute reminders already being provided, etc.) because the patient is consistently missing doses, etc. The report(s) can provide one or more recommended changes to a patient's medication, e.g., recommending switch from a cream to a pill since an inadequate amount of cream is consistently being dispensed for each dose, recommending a stronger prescribed strength of medication because rescue doses are consistently being taken between regularly scheduled doses, etc.
The incentives module 1010 can generally provide users of the system 1000 with a user interface for receiving one or more reports regarding one or more patients' adherence goals and one or more incentives for reaching each of the goals. The incentives module 1010 can be configured to provide a user of the system 1000 with at least one textual and/or graphic report indicating a selected patient's adherence goal(s) for a predetermined medication schedule and the patient's progress toward the goal(s). The incentives report(s) can thus reflect a patient's adherence to the patient's predetermined medication schedule. The incentives report(s) can help encourage patient adherence to predetermined medication schedules by providing rewards (virtual and/or physical) for achievement of goals, and/or the incentives report(s) can facilitate evaluating success of the patient's medication use, the patient's predetermined medication schedule, and/or the patient's overall treatment plan.
At least one incentive available for a patient can be based on a patient's performance of a predetermined number of specific tasks within a certain time period. The predetermined number can be predetermined by the incentives module 1010 and can optionally be customizable by a user, e.g., be adjusted by a patient's care provider. The user interface can be configured to display a patient's progress toward each of the patient's goals, such as by showing a percentage of the patient's met medication doses, by showing a progress bar indicating how many more particular events must take place to reach the goal, etc. The patient's progress can be shown simultaneously for all the goals, or the user interface can be configured to allow the user to select which progress, if any, to show on the user interface.
One example of an incentive based on a patient's performance of a predetermined number of specific tasks within a certain time period include a patient taking their medication on schedule a certain number of times within a certain time period (e.g., 90% of the time over the course of a month, 100% of the time over the course of a day, 100% of the time over the course of a week, 75% of the time over the course of a month, etc.). In other words, the goal for the patient can be adhering to their predetermined medication schedule a set number of times over the course of a preset time period.
Another example of an incentive based on a patient's performance of a predetermined number of specific tasks within a certain time period include a patient taking zero off-schedule doses of the medication. In other words, the goal for the patient can thus be avoiding emergency use of the medication.
Yet another example of an incentive based on a patient's performance of a predetermined number of specific tasks within a certain time period include a patient dispensing medication within a predetermined amount of time after a dosage of medication is due as indicated by the patient's predetermined medication schedule. In other words, the goal for the patient can include the patient dispensing medication on time a certain number of times, taking into account that medication will almost never be dispensed at the exact moment a notification is provided.
In addition to or instead of incentive(s) based on performance of certain tasks within a certain period of time, at least one incentive for a patient can be based on a patient's performance of a single specific task. One example of such an incentive includes the patient taking a dose of medication when scheduled to do so per the patient's predetermined medication schedule. In other words, the goal for the patient can be taking each prescribed medication dose. Another example of such an incentive includes the patient removing an accessory from one medication dispenser (e.g., a dispenser low on or empty of medication) and attaching the accessory to another medication dispenser (e.g., a dispenser full of medication). In other words, the goal for the patient can be ensuring that medication is always available for a required dose. Another example of such an incentive includes the patient inputting an answer to a pop-up question provided on the user interface. In other words, the goal for the patient can be providing requested input data.
In addition to or instead of incentive(s) based on performance of certain tasks within a certain period of time and/or being based on a patient's performance of a single specific task, at least one incentive for a patient can be based on a user other than the patient performing one or more certain tasks. The other user(s) performance of the task(s) can contribute to the patient's progress toward his/her goal(s), or the other user(s) performance of the task(s) can contribute to the other user's own goal(s) having reward(s) associated therewith. One example of such an incentive includes inputting an answer to a pop-up question provided on the user interface. In other words, the goal can be providing requested input data. Another example of such an incentive includes multiple users providing an answer to the same pop-up question, e.g., the patient and the patient's parent each provide an answer to the same pop-up question (e.g., “Why was emergency medication taken?”). If the patient and the other user(s) independently input the same answer to the same pop-op question, the contribution to the patient's progress toward his/her goal(s) can be accelerated. Communication between parties interested in the patient's health can therefore be facilitated. If the patient and the other user(s) input different answers to the same question, at least one of the patient and the other user(s) can be notified of the discrepancy, which can help facilitate open communication. For example, if a youth patient provides a different answer to a pop-question than the patient's parent, the parent can be notified (e.g., by interface icon, email, text message, etc.) so as to allow the parent to talk to their child about their medication usage even if the child does not independently approach their parent to discuss their medication.
Each goal can have at least one virtual reward and/or at least one physical reward associated therewith. Examples of virtual rewards include accessories for a user avatar shown on a user interface; achievement badge icons such as stars, shields, ribbons, smiley faces, animals, cartoon characters, etc. that can be displayed on a user interface; expanded choices of user avatars; points cumulatively tallied upon goal achievements to trigger other virtual and/or physical rewards based on point total; etc. Examples of physical rewards include a gift card for an online store and/or an actual stores; a coupon for a product, online store, and/or actual store; a free pass from a certain household chore; a printable certificate of achievement; a printable sticker; an IOU for a special treat (e.g., a trip to the zoo, seeing a movie of the patient's choice, a meal of the patient's choice prepared by someone in the patient's household; extra time for the patient to play with a certain toy; etc.); etc.
A goal can be known to a patient, which can allow the patient to actively be aware of and work toward the goal. However, a goal can be unknown to the patient such that achievement of the goal can result in a surprise reward. For example, an unknown goal can include a determination made by a patient's parent that the patient has been doing a good job keeping up with their medication and therefore deserves a reward, such as a virtual badge awarded by the parent to the patient that will appear on the patient's user interface the next time the user accesses the system. For example, an unknown goal can include a patient taking zero off-schedule doses of medication while otherwise taking a predetermined number or percentage of scheduled medication doses, which can help reward patients for adherence without discouraging patients from taking emergency medication when needed. For yet another example, an unknown goal can include a patient answering a certain number of pop-up questions provided on the user interface. After inputting answers to a predetermined number of questions, the patient can receive access to a set of previously locked accessories for their avatar. The patient can therefore learn that answering questions can result in rewards, thereby encouraging input of helpful data to the system.
The reward(s) associated with each goal can be predetermined by the system (e.g., a certain virtual reward for a certain achieved goal, a gift card of a certain monetary value for a certain web store if a certain number of daily goals are achieved a certain number of days in a row, etc.), or at least some goals can have user-customizable rewards (e.g., a monetary value amount of a gift card for a certain goal being able to be set by a parent of a youth patient; a congratulations message for a certain goal being customizable by the patient's care provider; a patient being able to select an avatar theme among a plurality of predetermined avatar themes, with each theme having a predetermined set of locked avatar accessories only unlocked so as to be accessible to the patient upon achievement of certain goals; a parent of a patient being able to select which of a plurality of web stores are acceptable stores for gift card rewards for the patient; a family member of a patient being able to identify how many points acquired through goal achievement are needed to excuse the patient from a certain household chore; a family member of a patient being able to identify a certain household chore that the patient can be excused from if a certain goal is met; etc.). Allowing at least some virtual and/or physical rewards to be customizable can help encourage adherence by allowing rewards to be chosen based on tastes of a particular patient so as to help maximize the patient's interest in adhering to their medication schedule; can allow the system to “grow” with a patient by allowing rewards to be changed to more appropriate rewards as the patient ages (e.g., increasing gift card values for older patients, changing excused chores, etc.); can allow the rewards to reflect time of year (e.g., having rewards reflect seasonal activities such as increased pool time in Summer for an achieved goal, a coupon for a discounted golf outing in Spring, a free pass from one day of snow shoveling in Winter, etc.), and/or can allow a reward for a goal to be changed to something bigger (e.g., a higher monetary value gift card, two avatar accessories instead of one, being excused from a chore for two weeks instead of one week, etc.) to help further encourage achievement of the goal; etc.
A patient, particularly a youth patient, may not even realize that adhering to their medication schedule is a necessary “chore,” or may not mind the “chore” at all or as much, because the incentives system can help turn adherence into a game, e.g., by providing fun graphics, by providing real world rewards that patients can use and/or see in real life, etc. Providing incentives can thus help encourage adherence in a fun, non-clinical way. Because the incentives system can be provided for individual use and can be used by patients of nearly any age (e.g., any patient old enough to be responsible for at least some of their own medication administration), the incentives system can make the patients feel more independent and/or can make adherence feel less stressful to a patient than if one or more people, e.g., the patient's care provider, parent or other family member, etc., are directly reminding the patient verbally and/or in writing to take their medication on schedule and/or are repeatedly asking the patient whether and when they took their medication.
The user interface can be configured to show a patient's incentives data for the patient as the user and to show a patient's incentives data for someone other than the patient. The incentives module 1010 can thus allow a patient to access their own incentives data, which can help motivate the patient toward achieving their goals. The incentives module 1010 allowing someone associated with the patient (e.g., a family member, a doctor, etc.) to access the incentives data can help involve parties concerned about the patient in the patient's treatment and/or can help allow goals and/or rewards to be adjusted as needed by a third party to help the patient adhere to their medication schedule.
The user interface 1700 can provide user identity information 1704 that identifies a current user. The user identity 1704 information can be helpful since the user interface 1700 can be customized for different users, such as show different avatars for different users, show clinical data to care providers, provide different user input fields to different users (e.g., allow a parent to change rewards, allow a patient to input a reason why a scheduled medication dose was missed, provide incentives data to a care provider for multiple patients at once, etc.), etc. In the illustrated embodiment, the user identity is “Billy,” a patient, with other possible user identities identified as “Parent” and “Doctor.”
The user interface 1700 can provide view options 1706 configured to allow the user to selectively view incentives data for different time periods. The view options 1706 in the illustrated embodiment include “Today's status,” “Daily,” “Weekly,” and “Monthly,” with “Today's status” being the currently selected view.
The user interface 1700 can provide patient data 1708, e.g., below a menu 1710 allowing selection of other information similar to the menu 1614 of
Although the invention has been described by reference to specific embodiments, a person skilled in the art will understand that numerous changes may be made within the spirit and scope of the inventive concepts described. A person skilled in the art will appreciate further features and advantages of the invention based on the above-described embodiments. Accordingly, the invention is not to be limited by what has been particularly shown and described, except as indicated by the appended claims. All publications and references cited herein are expressly incorporated herein by reference in their entirety.
The present application is a continuation of U.S. patent application Ser. No. 14/375,696, filed Jul. 30, 2014, which claims priority to International Application No. PCT/US2013/047507 entitled “Devices Systems, And Methods for Adherence Monitoring and Patient Interaction”, filed Jun. 25, 2013, and to U.S. Provisional Patent Application No. 61/664,008 entitled “System for Adherence Monitoring and Patient Interaction” filed on Jun. 25, 2012, which are hereby incorporated by reference in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4817822 | Rand et al. | Apr 1989 | A |
| 5042467 | Foley et al. | Aug 1991 | A |
| 5200891 | Edl et al. | Apr 1993 | A |
| 5284133 | Marshak et al. | Feb 1994 | A |
| 5331953 | Fagerstroem et al. | Jul 1994 | A |
| 5333106 | Lanpher et al. | Jul 1994 | A |
| 5338157 | Blomquist | Aug 1994 | A |
| 5363842 | Mishelevich et al. | Nov 1994 | A |
| 5505192 | Samiotes et al. | Apr 1996 | A |
| 5536249 | Castellano | Jul 1996 | A |
| 5544647 | Jewett et al. | Aug 1996 | A |
| 5544661 | Davis et al. | Aug 1996 | A |
| 5602802 | Leigh-Spencer et al. | Feb 1997 | A |
| 5622163 | Jewett et al. | Apr 1997 | A |
| 5642731 | Kehr et al. | Jul 1997 | A |
| 5752235 | Edl et al. | May 1998 | A |
| 5768382 | Walker et al. | Jun 1998 | A |
| 5779364 | Cannelongo et al. | Jul 1998 | A |
| 5809997 | Wolf et al. | Sep 1998 | A |
| 5828751 | Walker et al. | Oct 1998 | A |
| 5839429 | Marnfeldt et al. | Nov 1998 | A |
| 5842468 | Denyer et al. | Dec 1998 | A |
| 5887586 | Dahlbaeck et al. | Mar 1999 | A |
| 5970143 | Walker et al. | Oct 1999 | A |
| 5976082 | Wong et al. | Nov 1999 | A |
| 6018289 | Sekura et al. | Jan 2000 | A |
| 6039688 | Douglas et al. | Mar 2000 | A |
| 6084504 | Kort et al. | Jul 2000 | A |
| 6102855 | Chapman et al. | Aug 2000 | A |
| 6148815 | Wolf | Nov 2000 | A |
| 6168568 | Gavriely et al. | Jan 2001 | B1 |
| 6190326 | McKinnon et al. | Feb 2001 | B1 |
| 6198383 | Sekura et al. | Mar 2001 | B1 |
| 6202642 | McKinnon et al. | Mar 2001 | B1 |
| 6261238 | Gavriely et al. | Jul 2001 | B1 |
| 6285731 | Marnfeldt et al. | Sep 2001 | B1 |
| 6375623 | Gavriely et al. | Apr 2002 | B1 |
| 6383142 | Gavriely et al. | May 2002 | B1 |
| 6390088 | Noehl et al. | May 2002 | B1 |
| 6424599 | Ditzig et al. | Jul 2002 | B1 |
| 6540672 | Rokkjaer et al. | Apr 2003 | B1 |
| 6561022 | Doyle et al. | May 2003 | B1 |
| 6579231 | Phipps et al. | Jun 2003 | B1 |
| 6581357 | Lindenberger | Jun 2003 | B1 |
| 6604650 | Sagar | Aug 2003 | B2 |
| 6612985 | Eiffert et al. | Sep 2003 | B2 |
| 6637430 | Voges et al. | Oct 2003 | B1 |
| 6652455 | Kocher et al. | Nov 2003 | B1 |
| 6691058 | Blakley et al. | Feb 2004 | B2 |
| 6697649 | Bennett et al. | Feb 2004 | B1 |
| 6707763 | Osberg et al. | Mar 2004 | B2 |
| 6729327 | McFarland et al. | May 2004 | B2 |
| 6743202 | Hirschman et al. | Jun 2004 | B2 |
| 6747556 | Medema et al. | Jun 2004 | B2 |
| 6751730 | Walker et al. | Jun 2004 | B1 |
| 6804558 | Haller et al. | Oct 2004 | B2 |
| 6850555 | Barclay et al. | Feb 2005 | B1 |
| 6904907 | Speldrich et al. | Jun 2005 | B2 |
| 6937150 | Medema et al. | Aug 2005 | B2 |
| 6958691 | Anderson | Oct 2005 | B1 |
| 6978780 | Marnfeldt et al. | Dec 2005 | B1 |
| 6990975 | Jones et al. | Jan 2006 | B1 |
| 7016744 | Richard et al. | Mar 2006 | B2 |
| 7024331 | Jones et al. | Apr 2006 | B2 |
| 7072738 | Robertson et al. | Jul 2006 | B2 |
| 7081807 | Lai | Jul 2006 | B2 |
| 7133329 | Alvarez-Icaza et al. | Nov 2006 | B2 |
| 7138906 | Rosche et al. | Nov 2006 | B2 |
| 7139701 | Harton et al. | Nov 2006 | B2 |
| 7151456 | Godfrey et al. | Dec 2006 | B2 |
| 7170823 | Joergensen et al. | Jan 2007 | B2 |
| 7191777 | Brand et al. | Mar 2007 | B2 |
| 7198172 | Lintell et al. | Apr 2007 | B2 |
| 7201721 | Wilkinson et al. | Apr 2007 | B2 |
| 7205775 | Kreit et al. | Apr 2007 | B2 |
| 7228228 | Bartlett et al. | Jun 2007 | B2 |
| 7233228 | Lintell et al. | Jun 2007 | B2 |
| 7249687 | Anderson | Jul 2007 | B2 |
| 7295890 | Jean-Pierre et al. | Nov 2007 | B2 |
| 7330101 | Sekura et al. | Feb 2008 | B2 |
| 7343914 | Abrams et al. | Mar 2008 | B2 |
| 7347200 | Jones et al. | Mar 2008 | B2 |
| 7347824 | Wilkinson et al. | Mar 2008 | B2 |
| 7366675 | Walker et al. | Apr 2008 | B1 |
| 7383837 | Robertson et al. | Jun 2008 | B2 |
| 7395214 | Shillingburg | Jul 2008 | B2 |
| 7397730 | Bjorlig et al. | Jul 2008 | B2 |
| 7424888 | Lintell et al. | Sep 2008 | B2 |
| 7450974 | Bennett et al. | Nov 2008 | B2 |
| 7454267 | Robertson et al. | Nov 2008 | B2 |
| 7458373 | Grollimund et al. | Dec 2008 | B2 |
| 7461655 | Childers et al. | Dec 2008 | B2 |
| 7481213 | Childers et al. | Jan 2009 | B2 |
| 7495546 | Lintell | Feb 2009 | B2 |
| 7515507 | Nanda et al. | Apr 2009 | B2 |
| 7537005 | Dave | May 2009 | B2 |
| 7553234 | Walker et al. | Jun 2009 | B2 |
| 7554434 | Gifford et al. | Jun 2009 | B1 |
| 7639120 | Sekura et al. | Dec 2009 | B2 |
| 7675424 | Debord et al. | Mar 2010 | B2 |
| 7680629 | Chang et al. | Mar 2010 | B2 |
| 7708697 | Wilkinson et al. | May 2010 | B2 |
| 7766012 | Scheuch et al. | Aug 2010 | B2 |
| 7772981 | Lambert et al. | Aug 2010 | B1 |
| 7796676 | Barclay et al. | Sep 2010 | B2 |
| 7810745 | Oomura et al. | Oct 2010 | B2 |
| 7819116 | Brand et al. | Oct 2010 | B2 |
| 7821404 | Bean et al. | Oct 2010 | B2 |
| 7837648 | Blair et al. | Nov 2010 | B2 |
| 7844361 | Jean-Pierre et al. | Nov 2010 | B2 |
| 7850618 | Wilkinson et al. | Dec 2010 | B2 |
| RE42052 | Donaldson et al. | Jan 2011 | E |
| 7868609 | Zhitomirskiy et al. | Jan 2011 | B2 |
| 7944342 | Sekura et al. | May 2011 | B2 |
| 7945461 | Sekura et al. | May 2011 | B2 |
| 7996106 | Ervin et al. | Aug 2011 | B2 |
| 8032397 | Lawless et al. | Oct 2011 | B2 |
| 8055509 | Walker et al. | Nov 2011 | B1 |
| 8066432 | Guo et al. | Nov 2011 | B2 |
| 8069056 | Walker et al. | Nov 2011 | B2 |
| 8091545 | Schechter et al. | Jan 2012 | B2 |
| 8092224 | Bean et al. | Jan 2012 | B2 |
| 8129985 | Jones et al. | Mar 2012 | B2 |
| 8138939 | Manning et al. | Mar 2012 | B2 |
| 8149111 | Monroe et al. | Apr 2012 | B2 |
| 8215299 | Wu et al. | Jul 2012 | B2 |
| 8225781 | Ooida et al. | Jul 2012 | B2 |
| 8231573 | Edwards et al. | Jul 2012 | B2 |
| 8240301 | Spaargaren et al. | Aug 2012 | B2 |
| 8241223 | Gavriely et al. | Aug 2012 | B2 |
| 8262394 | Bean et al. | Sep 2012 | B2 |
| 8269613 | Lazar et al. | Sep 2012 | B2 |
| 8279076 | Johnson | Oct 2012 | B2 |
| 8284068 | Johnson et al. | Oct 2012 | B2 |
| 8286821 | Mejia et al. | Oct 2012 | B2 |
| 8290792 | Sekura et al. | Oct 2012 | B2 |
| 8311770 | Park et al. | Nov 2012 | B2 |
| 8319613 | Lazar et al. | Nov 2012 | B2 |
| 8342172 | Levy et al. | Jan 2013 | B2 |
| 8353752 | Walker et al. | Jan 2013 | B2 |
| 8386042 | Yudovsky et al. | Feb 2013 | B2 |
| 8424517 | Sutherland et al. | Apr 2013 | B2 |
| 8446799 | Burke et al. | May 2013 | B2 |
| 8448873 | Downey et al. | May 2013 | B2 |
| 8456287 | Gifford et al. | Jun 2013 | B2 |
| 8464707 | Jongejan et al. | Jun 2013 | B2 |
| 8485982 | Gavish et al. | Jul 2013 | B2 |
| 8488505 | Pyles et al. | Jul 2013 | B2 |
| 8502692 | Johnson | Aug 2013 | B2 |
| 8517016 | Caro et al. | Aug 2013 | B2 |
| 8528544 | Kobayashi et al. | Sep 2013 | B2 |
| 8534220 | Olson et al. | Sep 2013 | B1 |
| 8538707 | Polidoro et al. | Sep 2013 | B2 |
| 8539945 | Solomon et al. | Sep 2013 | B2 |
| 8544286 | Janssen et al. | Oct 2013 | B2 |
| 8547239 | Peatfield et al. | Oct 2013 | B2 |
| 8549310 | Walker et al. | Oct 2013 | B2 |
| 8550069 | Alelov | Oct 2013 | B2 |
| 8560271 | Koehler et al. | Oct 2013 | B2 |
| 8573203 | Addington et al. | Nov 2013 | B2 |
| 8615413 | McKee et al. | Dec 2013 | B2 |
| 8666539 | Ervin et al. | Mar 2014 | B2 |
| 8710827 | Zhitomirsky et al. | Apr 2014 | B2 |
| 8714150 | Alelov | May 2014 | B2 |
| 8714983 | Kil et al. | May 2014 | B2 |
| 8725529 | Hyde et al. | May 2014 | B2 |
| 8727180 | Way et al. | May 2014 | B2 |
| 8738395 | Hyde et al. | May 2014 | B2 |
| 8750693 | Sharma et al. | Jun 2014 | B2 |
| 8754769 | Stein et al. | Jun 2014 | B2 |
| 8771205 | Gavriely et al. | Jul 2014 | B2 |
| 8797167 | Hyde et al. | Aug 2014 | B2 |
| 8807131 | Chan et al. | Aug 2014 | B1 |
| 8823510 | Downey et al. | Sep 2014 | B2 |
| 8830076 | Smith et al. | Sep 2014 | B2 |
| 8838738 | Lee et al. | Sep 2014 | B2 |
| 8844766 | Zaima et al. | Sep 2014 | B2 |
| 8854225 | Johnson | Oct 2014 | B2 |
| 8857617 | Gosselin et al. | Oct 2014 | B2 |
| 8869793 | Spandorfer et al. | Oct 2014 | B1 |
| 8896428 | Shalala et al. | Nov 2014 | B2 |
| 8909487 | Polidoro et al. | Dec 2014 | B2 |
| 8922367 | Denny et al. | Dec 2014 | B2 |
| 8960189 | Morrison | Feb 2015 | B2 |
| 8976036 | Johnson | Mar 2015 | B2 |
| 8997735 | Zierenberg et al. | Apr 2015 | B2 |
| 9007875 | Nurse et al. | Apr 2015 | B2 |
| 9014427 | Bear et al. | Apr 2015 | B2 |
| 9027795 | Ahlgren et al. | May 2015 | B2 |
| 9046403 | Ziemba et al. | Jun 2015 | B2 |
| 9056174 | Bradshaw et al. | Jun 2015 | B2 |
| 9058410 | McKee et al. | Jun 2015 | B2 |
| 9072654 | Pentz | Jul 2015 | B2 |
| 9081885 | Bangera et al. | Jul 2015 | B2 |
| 9084566 | Zdeblick | Jul 2015 | B2 |
| 9125798 | Stein et al. | Sep 2015 | B2 |
| 9145000 | Lakin et al. | Sep 2015 | B2 |
| 9168343 | Scarrott et al. | Oct 2015 | B2 |
| 9174009 | Peatfield et al. | Nov 2015 | B2 |
| 9188579 | Shen et al. | Nov 2015 | B2 |
| 9216267 | Spandorfer et al. | Dec 2015 | B2 |
| 9235689 | Ervin et al. | Jan 2016 | B2 |
| 9235690 | Jain et al. | Jan 2016 | B2 |
| 9242056 | Andersen et al. | Jan 2016 | B2 |
| 9272531 | Starkey et al. | Mar 2016 | B2 |
| 9278177 | Edwards et al. | Mar 2016 | B2 |
| 9283027 | Green et al. | Mar 2016 | B2 |
| 9295793 | O'Hara et al. | Mar 2016 | B2 |
| 9308151 | Soon-Shiong et al. | Apr 2016 | B2 |
| 9308334 | Smetham et al. | Apr 2016 | B2 |
| 9311452 | Dickie et al. | Apr 2016 | B2 |
| 9314292 | Trees et al. | Apr 2016 | B2 |
| 9317663 | Dickie et al. | Apr 2016 | B2 |
| 9339188 | Proud | May 2016 | B2 |
| 9339616 | Denny et al. | May 2016 | B2 |
| 9352107 | Von Hollen et al. | May 2016 | B2 |
| 9358183 | Stein et al. | Jun 2016 | B2 |
| 9361431 | Fauci et al. | Jun 2016 | B2 |
| 9361772 | Johnson | Jun 2016 | B2 |
| 9361780 | Tomasi et al. | Jun 2016 | B2 |
| 9364619 | Polidoro et al. | Jun 2016 | B2 |
| 9392939 | Proud | Jul 2016 | B2 |
| 9398854 | Proud | Jul 2016 | B2 |
| 9427534 | Bruin et al. | Aug 2016 | B2 |
| 9460265 | Burrows et al. | Oct 2016 | B2 |
| 9463291 | Imran | Oct 2016 | B2 |
| 9468729 | Sutherland et al. | Oct 2016 | B2 |
| 9501626 | Nathan et al. | Nov 2016 | B2 |
| 9542826 | Edwards et al. | Jan 2017 | B2 |
| 9550031 | Van Sickle et al. | Jan 2017 | B2 |
| 9694147 | Peatfield et al. | Jul 2017 | B2 |
| 9736642 | Ostrander et al. | Aug 2017 | B2 |
| 9839398 | Yamamori et al. | Dec 2017 | B2 |
| 9911308 | Edwards et al. | Mar 2018 | B2 |
| 9956360 | Germinario et al. | May 2018 | B2 |
| 9962507 | Germinario et al. | May 2018 | B2 |
| 9962508 | Bruin et al. | May 2018 | B2 |
| 10016134 | Hansen et al. | Jul 2018 | B2 |
| 10046121 | Kolb et al. | Aug 2018 | B2 |
| 10155094 | Wachtel et al. | Dec 2018 | B2 |
| 10300227 | Sutherland | May 2019 | B2 |
| 10556070 | Van Sickle et al. | Feb 2020 | B2 |
| 20010028308 | De La Huerga | Oct 2001 | A1 |
| 20020073196 | Westervelt et al. | Jun 2002 | A1 |
| 20020185128 | Theobald et al. | Dec 2002 | A1 |
| 20030098022 | Nakao et al. | May 2003 | A1 |
| 20030099158 | De la Huerga | May 2003 | A1 |
| 20030192535 | Christrup et al. | Oct 2003 | A1 |
| 20030234198 | Weinstein et al. | Dec 2003 | A1 |
| 20040089299 | Bonney et al. | May 2004 | A1 |
| 20040117062 | Bonney et al. | Jun 2004 | A1 |
| 20040148199 | Dixon et al. | Jul 2004 | A1 |
| 20040199056 | Husemann et al. | Oct 2004 | A1 |
| 20050021286 | Kunce et al. | Jan 2005 | A1 |
| 20050028815 | Deaton et al. | Feb 2005 | A1 |
| 20050086256 | Owens et al. | Apr 2005 | A1 |
| 20050119604 | Bonney et al. | Jun 2005 | A1 |
| 20050150488 | Dave et al. | Jul 2005 | A1 |
| 20050161467 | Jones et al. | Jul 2005 | A1 |
| 20050172958 | Singer et al. | Aug 2005 | A1 |
| 20050247312 | Davies et al. | Nov 2005 | A1 |
| 20050251289 | Bonney et al. | Nov 2005 | A1 |
| 20060089545 | Ratjen et al. | Apr 2006 | A1 |
| 20060231109 | Howell et al. | Oct 2006 | A1 |
| 20060237001 | Stangl et al. | Oct 2006 | A1 |
| 20060237002 | Bonney et al. | Oct 2006 | A1 |
| 20060241510 | Halperin et al. | Oct 2006 | A1 |
| 20070023034 | Jongejan et al. | Feb 2007 | A1 |
| 20070118054 | Pinhas et al. | May 2007 | A1 |
| 20070186923 | Poutiatine et al. | Aug 2007 | A1 |
| 20070271298 | Juang et al. | Nov 2007 | A1 |
| 20080114490 | Jean-Peirre | May 2008 | A1 |
| 20080125724 | Monroe et al. | May 2008 | A1 |
| 20080173301 | Deaton et al. | Jul 2008 | A1 |
| 20080201169 | Galasso et al. | Aug 2008 | A1 |
| 20080230057 | Sutherland | Sep 2008 | A1 |
| 20080269625 | Halperin et al. | Oct 2008 | A1 |
| 20080281636 | Jung et al. | Nov 2008 | A1 |
| 20090128330 | Monroe et al. | May 2009 | A1 |
| 20090194104 | Van et al. | Aug 2009 | A1 |
| 20090221308 | Lerner et al. | Sep 2009 | A1 |
| 20090308387 | Andersen et al. | Dec 2009 | A1 |
| 20090314292 | Overfield et al. | Dec 2009 | A1 |
| 20090326861 | Langford et al. | Dec 2009 | A1 |
| 20100164716 | Estevez et al. | Jul 2010 | A1 |
| 20100192948 | Sutherland et al. | Aug 2010 | A1 |
| 20100242960 | Zangerle et al. | Sep 2010 | A1 |
| 20100250280 | Sutherland et al. | Sep 2010 | A1 |
| 20100252036 | Sutherland et al. | Oct 2010 | A1 |
| 20110253139 | Guthrie et al. | Oct 2011 | A1 |
| 20110282693 | Craft | Nov 2011 | A1 |
| 20120123842 | Patel et al. | May 2012 | A1 |
| 20120173319 | Ferrara et al. | Jul 2012 | A1 |
| 20120232983 | Bertha et al. | Sep 2012 | A1 |
| 20120245960 | Bartholomew et al. | Sep 2012 | A1 |
| 20130053719 | Wekell | Feb 2013 | A1 |
| 20130096843 | Yuen et al. | Apr 2013 | A1 |
| 20130137998 | Lange et al. | May 2013 | A1 |
| 20130144178 | Halperin et al. | Jun 2013 | A1 |
| 20130151196 | Yuen et al. | Jun 2013 | A1 |
| 20130245502 | Lange et al. | Sep 2013 | A1 |
| 20130269685 | Jung et al. | Oct 2013 | A1 |
| 20130269694 | Patton et al. | Oct 2013 | A1 |
| 20130304502 | Cederlund et al. | Nov 2013 | A1 |
| 20130325396 | Yuen et al. | Dec 2013 | A1 |
| 20130325399 | Yuen et al. | Dec 2013 | A1 |
| 20130325404 | Yuen et al. | Dec 2013 | A1 |
| 20140000598 | Sutherland et al. | Jan 2014 | A1 |
| 20140012099 | Halperin et al. | Jan 2014 | A1 |
| 20140039839 | Yuen et al. | Feb 2014 | A1 |
| 20140039840 | Yuen et al. | Feb 2014 | A1 |
| 20140039841 | Yuen et al. | Feb 2014 | A1 |
| 20140039842 | Yuen et al. | Feb 2014 | A1 |
| 20140052790 | Yuen et al. | Feb 2014 | A1 |
| 20140065219 | Bosch et al. | Mar 2014 | A1 |
| 20140106324 | Adams et al. | Apr 2014 | A1 |
| 20140155841 | Dossin et al. | Jun 2014 | A1 |
| 20140182584 | Sutherland et al. | Jul 2014 | A1 |
| 20140207204 | Halperin et al. | Jul 2014 | A1 |
| 20140213925 | Chan et al. | Jul 2014 | A1 |
| 20150193597 | Cederlund | Jul 2015 | A1 |
| 20150283341 | Adams et al. | Oct 2015 | A1 |
| 20160042154 | Goldberg et al. | Feb 2016 | A1 |
| 20160082208 | Ballam et al. | Mar 2016 | A1 |
| 20160103966 | Mirza et al. | Apr 2016 | A1 |
| 20160128389 | Lamb et al. | May 2016 | A1 |
| 20160166766 | Schuster et al. | Jun 2016 | A1 |
| 20160228657 | Sutherland | Aug 2016 | A1 |
| 20160256639 | Van Sickle et al. | Sep 2016 | A1 |
| 20160314256 | Su et al. | Oct 2016 | A1 |
| 20170079557 | Lauk | Mar 2017 | A1 |
| 20170109493 | Hogg et al. | Apr 2017 | A1 |
| 20170140125 | Hogg et al. | May 2017 | A1 |
| 20170164892 | Sezan et al. | Jun 2017 | A1 |
| 20170173279 | Sutherland et al. | Jun 2017 | A1 |
| 20170246406 | Sutherland | Aug 2017 | A1 |
| 20170258993 | Pizzochero et al. | Sep 2017 | A1 |
| 20170262613 | Ljungberg | Sep 2017 | A1 |
| 20170270260 | Shetty | Sep 2017 | A1 |
| 20170325734 | Sutherland et al. | Nov 2017 | A1 |
| 20170363673 | Mukherjee | Dec 2017 | A1 |
| 20180011988 | Ziegler et al. | Jan 2018 | A1 |
| 20180052964 | Adelson | Feb 2018 | A1 |
| 20180085540 | Dantsker et al. | Mar 2018 | A1 |
| 20180125365 | Hunter et al. | May 2018 | A1 |
| 20180161530 | Ganton et al. | Jun 2018 | A1 |
| 20210074402 | Levin | Mar 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 202289119 | Jul 2012 | CN |
| 204864412 | Dec 2015 | CN |
| 205073444 | Mar 2016 | CN |
| 205073448 | Mar 2016 | CN |
| 1135056 | Aug 2006 | EP |
| 1688746 | Aug 2006 | EP |
| 1736133 | Dec 2006 | EP |
| 1970087 | Sep 2008 | EP |
| 1992381 | Nov 2008 | EP |
| 1423046 | Jan 2010 | EP |
| 2186471 | May 2010 | EP |
| 2384782 | Nov 2011 | EP |
| 3228345 | Oct 2017 | EP |
| 2987997 | Sep 2013 | FR |
| 9522365 | Aug 1995 | WO |
| 9838909 | Sep 1998 | WO |
| 9953982 | Oct 1999 | WO |
| 9963901 | Dec 1999 | WO |
| 0002779 | Jan 2000 | WO |
| 0032088 | Jun 2000 | WO |
| 0124690 | Apr 2001 | WO |
| 0126020 | Apr 2001 | WO |
| 0200280 | Jan 2002 | WO |
| 02053022 | Jul 2002 | WO |
| 03063754 | Aug 2003 | WO |
| 03073977 | Sep 2003 | WO |
| 2004084116 | Sep 2004 | WO |
| 2005028008 | Mar 2005 | WO |
| 2006068623 | Jun 2006 | WO |
| 2009003989 | Jan 2009 | WO |
| 2010098927 | Sep 2010 | WO |
| 2011135353 | Nov 2011 | WO |
| 2012095829 | Jul 2012 | WO |
| 2012110700 | Aug 2012 | WO |
| 2013126897 | Aug 2013 | WO |
| 2015002492 | Jan 2015 | WO |
| 2016043601 | Mar 2016 | WO |
| 2017005605 | Jan 2017 | WO |
| 2017051389 | Mar 2017 | WO |
| 2017129521 | Aug 2017 | WO |
| 2017141194 | Aug 2017 | WO |
| 2017176693 | Oct 2017 | WO |
| 2017176704 | Oct 2017 | WO |
| 2017180980 | Oct 2017 | WO |
| 2017189712 | Nov 2017 | WO |
| 2018128976 | Jul 2018 | WO |
| 2018134552 | Jul 2018 | WO |
| 2018134553 | Jul 2018 | WO |
| Entry |
|---|
| Tsai et al. 2010, “iMAT: Intelligent medication administration tools,” The 12th IEEE International Conference on e-Health Networking, Applications and Services, Lyon, France, 2010, pp. 308-315, doi: 10.1109/HEALTH.2010.5556551. |
| Varshney 2011, “Wireless Medication Management System: Design and performance evaluation,” 2011 Wireless Telecommunications Symposium (WTS), New York, NY, USA, 2011, pp. 1-8, doi: 10.1109/WTS.2011.5960858. |
| Bateman , et al., “Can Guideline-Defined Asthma Control be Achieved? The Gaining Optimal Asthma Control Study”, Am. J. Respir. Crit. Care Med., vol. 170, No. 8, Jan. 1, 2004 00:00:00.0, pp. 836-844. |
| Doser , “Doser™ Product Description”, Available at https://www.doser.com/dWhat.html, retrieved on Jun. 22, 2017, Jan. 1, 1999 00:00:00.0, 2 pages. |
| Frey , et al., “Complexity of Chronic Asthma and Chronic Obstructive Pulmonary Disease: Implications for Risk Assessment, and Disease Progression and Control”, Lancet, vol. 372, No. 9643, Jan. 1, 2008 00:00:00.0, pp. 1088-1099. |
| Isonea , “Technology”, Available at https://web.archive.org/web/20131012033714/http:/isoneamed .com/products/productstechnolog, Jan. 1, 2011 00:00:00.0, 3 pages. |
| Miller , “Attacking Asthma with Advanced Telehealth Monitoring”, AT&T, http://www.research.att.com/articles/featured_stories/2012_12/201212_asthma_VOC_detector.html?fbid=5Z7y-IAVNCi, Dec. 17, 2012 00:00:00.0, 3 pages. |
| Moorman , et al., “National Surveillance for Asthma”, Morbidity and Mortality Weekly Report. US, vol. 56, No. SS-8, Jan. 1, 2007 00:00:00.0, 57 pages. |
| Nathan , et al., “Development of the Asthma Control Test: A Survey for Assessing Asthma Control”, J. Allergy Clin. Immunol, vol. 113, No. 1, Jan. 1, 2004 00:00:00.0, pp. 59-65. |
| National Heart, Lung, and Blood , “Expert Panel Report 3: Guidelines for the Diagnosis and Management of Asthma Full Report”, Full Report, U.S, Aug. 28, 2007 00:00:00.0, 440 pages. |
| Nike , “Nike+ Fuelband”, Available at https://web.archive.org/web/20130106020727 /http://www.nike.com/us/en_us/lp/nikeplusfuelband, Jan. 1, 2012 00:00:00.0, 17 pages. |
| Propeller Health , “How It Works”, Available at http://propellerhealth.com/solutions/, Jan. 1, 2013 00:00:00.0, 5 pages. |
| Propeller Health , “Patients”, Available at http://propellerhealth.com/solutions/patients, Jan. 1, 2013 00:00:00.0, 5 pages. |
| Propeller Health , “Payers”, Available at http://propellerhealth.com/solutions/payers, Jan. 1, 2013 00:00:00.0, 5 pages. |
| Propeller Health , “Providers”, Available at http://propellerhealth.com/solutions/providers, Jan. 1, 2013 00:00:00.0, 4 pages. |
| Smartinhaler , “Smartinhaler Tracker”, Available at https://web.archive.org/web/20130125222221/http:/www.smartinhaler.com/clinical/products/smartinhalertracker.aspx, Jan. 1, 2011 00:00:00.0, 1 page. |
| Tsai, P. , et al., “Smart Medication Dispenser: Design, Architecture and Implementation”, IEEE Systems Journal, vol. No. 5, No. 1, Mar. 2011, 99-110. |
| Number | Date | Country | |
|---|---|---|---|
| 20220143335 A1 | May 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61664008 | Jun 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14375696 | US | |
| Child | 17572103 | US |
