US20230410166A1 - Facilitating integrated behavioral support through personalized adaptive data collection - Google Patents

Abstract

The present invention includes various embodiments of a BSA system that facilitates the collection of relevant health-related data on a continuous basis, integrates such data with pertinent personal and aggregate information, enables users to purchase (directly and indirectly) health-related goods and services, and provides credit, discounts and other economic benefits in connection with such purchases that are determined dynamically based upon the nature and extent of users' interaction with the system. The BSA system facilitates a dynamic feedback process by continually monitoring user interaction and medical and financial behavior, which results in dynamic adjustments to their credit levels and offers of discounts and other promotions, which in turn incentivizes users to continue participating in the process (thereby modifying their system interactions and behavior, and thus perpetuating this feedback loop). As a result, users are incentivized to actively participate in the process and thereby enhance their wellness while reducing healthcare costs.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 14/857,034, flied on Sep. 17, 2015, which claims the benefit of continuation-in-part of U.S. patent application Ser. No. 14/217,165, filed Mar. 17, 2014, which claims the benefit, pursuant to 35 U.S.C. § 119(e), of U.S. Provisional Patent Application No. 61/801,454, filed Mar. 15, 2013, all of which are hereby incorporated by reference in their entirety.
BACKGROUNDField of Art
• The present invention relates generally to interactive support and modification of user behavior patterns, and more particularly to interactive healthcare and a novel variation of a behavioral support agent that incentivizes individuals to interact with and actively participate in utilizing online resources to enhance their overall wellness, it adaptively modifies the type and frequency of data collection based upon users' changing personal circumstances.
Description of Related Art
• As the Internet evolves, access to information, including health-related information, continues to increase exponentially. Individuals currently have instant online access, from a wide variety of sources, to personal and aggregate information relating to patient histories, test results, physical and mental fitness, nutrition, health supplements, and a vast array of health research, as well as methods and devices for measuring, diagnosing and treating various conditions or simply enhancing overall wellness.
• Moreover, the advent of “smart” mobile devices and related technologies has provided individuals with access to such information on a continuous basis, as well as the ability to monitor health-related data (heart rate, blood pressure, etc.) and receive feedback covering virtually any period of time, including events such as a workout or a night's sleep.
• However, this vast of array of information and device technology is far from integrated, and can be overwhelming to individuals. How does a layperson even identify relevant symptoms, much less sift through the vast array of available information “on demand” to obtain useful results? And how personalized are those results given the limited amount of data provided by a few search terms? Does a search engine know what medications patients are taking, or whether they recently stopped taking a particular medication, or took another substance or engaged in an activity that, in combination, might explain certain symptoms?
• There is clearly a need for a more holistic approach, particularly in light of the state of the technology currently available. In essence, there is a need fora “behavioral support agent” (BSA) that can facilitate the collection of relevant data on a continual basis, modify the type and frequency of such data collection based on changing circumstances, integrate such data with pertinent aggregate information, and guide individuals toward behaviors that will enhance their overall wellness.
• Various attempts to address one or more aspects of this problem have been implemented or proposed. For example, websites such as WebMD provide users with the ability to search an extensive database of health-related information. In addition to providing a searchable database, other features include a “symptom checker” (which provides potential diagnoses based upon users' answers to questions relating to symptoms) and a “medication tracker” (which enables users to maintain lists of their current medications, and provides information relating to drug interactions, side effects, and FDA warnings). As noted above, however, such “on demand” systems provide limited personalization, as the information they provide is based on keyword searches rather than personal health-related data adaptively collected on a continual basis over time.
• Other websites and smartphone apps are targeted at specific aspects of healthcare, such as maintaining personal medical records or medication profiles (e.g., HealthVault or MphRx) or monitoring activity and fitness levels, often in connection with user monitoring devices (e.g., FitBit). While some of these approaches may be more engaging than searchable websites, they do not take a holistic approach. Beyond specific activities such as walking, running or taking a pill, they lack comprehensive day-to-day and historical monitoring of users' symptoms, schedules and overall health conditions and the ability to adaptively collect, utilize and respond to such data to support users and enable them to improve their health outcomes.
• Other systems have adopted a more holistic approach to this problem. For example, U.S. Pat. No. 8,170,609 discloses a personal virtual assistant system that includes a remote station carried by users which has one or more physiological sensors, and a rules engine that provides advice to users based in part upon the sensor data. Other systems have attempted to reduce the need for human intervention in routine aspects of healthcare by programming virtual assistants to aid users in various tasks. For instance, the “Alme” virtual assistant platform from NextIT provides automated aid with navigation of choices for users. It has been recently deployed by Aetna to help members navigate their website better. Ann, Alme's virtual assistant deployed by Aetna, is able to help the insured register on the website, get cost of service estimates, locate in-network providers and compare costs by facilities and physicians. Implementing Ann has enabled Aetna to cut costs by reducing the burden on their call center.
• While some of these proposed “solutions” take a more patient-centric and preventive approach to wellness, some key obstacles remain unaddressed, even by existing virtual assistant systems. For example, healthcare is an expensive proposition. Regardless of the quality of the information obtained online, individuals may still find it necessary or desirable from time to time to visit clinics, hospitals, doctors and other specialists, and purchase medications, supplements, health monitoring devices and other health-related goods and services. The cost of such health-related goods and services can be quite significant, despite preventive measures. Additional cost-reduction efforts are still needed to address this problem effectively.
• Moreover, as is the case with healthcare generally, the quality of information generated by any of these systems depends greatly upon the degree to which individuals participate in the process and interact with the system. For example, individuals will derive greater benefits if they provide timely and accurate information, follow system suggestions and provide frequent feedback regarding their activities, likes, dislikes and so forth. While users may initially provide profile information and frequently interact with a new system, human behavior is such that, in most cases, their level of interaction quickly tapers off.
• While a BSA system could prompt users for relevant information on a timely basis and provide entertaining content in an effort to keep users engaged, additional incentives are needed to maintain sufficient patient participation in the process. Though seemingly unrelated, these problems of high healthcare costs and inadequate patient participation provide an opportunity for a novel approach that “kills two birds with one stone.”
• A key deficiency of existing systems is their lack of connection to the “healthcare transaction flow” through which users purchase health-related goods and services. If a BSA system could insert itself into this transaction flow, and provide users with economic incentives (credit, discounts, etc.) based upon the nature and extent of their interaction with the system, such additional economic incentives would complete a feedback loop that reduces healthcare costs as a means of encouraging active user participation, which in turn enhances overall wellness.
• Not surprisingly, some financial services companies have delved into the healthcare sector. For example, Citigroup's “Money²for Health” project, is a payment processing and reconciliation system (online automated “spreadsheet” with integrated payment transaction capability) that allows consumers to maintain payment history and make payments from one portal to all healthcare providers and insurance companies registered on the site. But, this project neither includes nor suggests any connection to a BSA system, much less any reliance on patients' interaction with such a system as a factor in assessing benefits provided to patients, such as credit and discounts on the purchase of health-related goods and services.
• While financial services companies such as Klarna (a European mobile payment provider based in Sweden), have experimented with “micro credit” and various other credit-assessment techniques (see, e.g., published patent applications WO/2013131971 and US/2011030738), no such company has even suggested targeting credit-assessment techniques at purchases of health-related goods and services, much less basing credit assessments on users' interaction with a BSA system.
• Moreover, none of these existing systems employs a personalized approach to data collection, e.g., by adaptively modifying the type and frequency of data collection based upon users' changing personal circumstances.
• Thus, there remains a need for a BSA system that addresses the problems of high healthcare costs and inadequate patient participation by enabling users to purchase health-related goods and services via their user accounts, adaptively modifying the type and frequency of data collection in a personalized manner, and automatically and dynamically providing economic incentives to users based upon the nature and extent of their interaction with the system.
SUMMARY
• To address the above-referenced problems, the present invention includes various embodiments of a BSA system that facilitates the collection of user related data, including their relevant activities, on a continual and adaptive basis, integrates such data with other pertinent personal and aggregate information, and guides users toward behaviors that help achieve system level and user specific goals such as enhancement of the user's overall wellness. The BSA system applies to any sphere of user activity, such as entertainment, travel or overall lifestyle, commercial transactions etc., but is described herein with regard to its application in healthcare and wellness support. The BSA system enables users to purchase health-related goods and services (directly using the system, as well as indirectly via their user accounts), while providing credit, discounts and other economic benefits in connection with such purchases that are determined dynamically based upon the nature and extent of users' interaction with the system.
• In one embodiment, the BSA system continually monitors and analyzes users' behavioral interactions with the system. This health-related behavior includes various factors relating to the nature and frequency of information the user provides to and receives from the system (e.g., queries and responses, symptoms and other shared health status information, content browsed, games played, interactions with other users on social networks, health-related purchases, and shared third-party lab results, fitness data and other external information, among other factors).
• In another embodiment, the type and frequency of data collection is adaptively modified based upon users' changing personal circumstances. For example, based upon symptoms or other diagnostic data collected over time, the system may not only detect a problem requiring certain follow-up actions (e.g., recommending and scheduling a visit to a doctor or specialist), but may also increase the frequency of the data being collected (e.g., hourly instead of daily monitoring of blood pressure) as well as the type of data collected (e.g., adding a new heart-rate test perhaps via the same wearable device that tests blood pressure). As a result, the doctor or specialist may have more relevant data to analyze or may cancel the visit should the symptoms subside based upon the additional data collected.
• Triggers for modifying the type and frequency of data collection include (among others) indicators of a new significant or potentially significant medical condition (e.g., a persistent cough), detected changes to a user's “normal” status over time, and even a current outbreak in a user's local geographic area (which might trigger actions to identify other users who are similarly affected, or potentially at risk). By increasing the frequency and adjusting the type of data collection when warranted by various triggers, this technique can be analogized to a form of “signal compression” that only increases sampling frequency when it detects movement or changes.
• This adaptive approach to data collection can also be analogized to a “universal doctor” who knows all patients intimately and provides personalized services to patients who benefit from the aggregate knowledge accumulated from other patients. By continuously collecting data from users and refining the type and frequency of data collection in a personalized manner, the present invention enables results beyond those achievable by any individual doctor or other health professional. It should be noted that adaptive data collection methodologies may also include follow-up questions or other data collection techniques, as well as manual and automated data sensors and monitors that target not only individual users but also dynamically identified groups of users. Various other personalized adaptive data collection scenarios will be discussed in greater detail below.
• In yet another embodiment, users accumulate and lose points, based upon the nature and frequency of virtually all of these direct and indirect Interactions with the system. Various algorithms are employed to convert this raw data into particular attributes of credit levels, discounts for specific health-related products and services, and other benefits.
• A Benefits Engine assesses the appropriate amount of credit (as well as discounts and other promotions) to offer users based upon this multi-dimensional data. Over time, the Benefits Engine may raise or lower a user's credit level (credit limit, interest rate, appropriateness of particular purchases, etc.) and reward the user with particular discounts, based upon dynamic changes in the user's behavior, as well as standard financial profile and transactional behavior data (including timeliness of payments to the BSA system provider).
• The BSA system facilitates this dynamic feedback process by continually monitoring user interaction and medical and financial behavior, which results in dynamic adjustments to their credit levels and offers of discounts and other promotions, which in turn incentivizes users to continue participating in the process (thereby modifying their system interactions and behavior, and thus perpetuating this feedback loop). As a result, users are incentivized to actively participate in the process and thereby enhance their wellness while reducing healthcare costs.
• For example, if a user frequently browses or searches for information relating to a particular nutritional supplement, and provides periodic information relating to their usage of that supplement over time, this behavior suggests that the user places a relatively high value on that supplement, perhaps justifying a discount on that supplement (or on related products and services). Moreover, the user may in fact value that supplement over other non-healthcare-related items (e.g., a cable bill), perhaps justifying a higher credit limit and/or lower interest rate in connection with purchases of health-related goods and services via their user account.
• The credit assessment process of the present invention involves consideration not only of standard financial profile and transactional behavior data, but also of specific health-related behavioral data, which is particularly relevant given that user credit is targeted at financing purchases of health-related goods and services. In one embodiment, aggregate behavior of others (including other BSA system users, or a correlated subset of such users) is also considered in the credit-assessment process, as well as in the determination of which discounts, or other benefits (including targeted advertisements and product promotions) are offered to particular users.
• Rather than address merely a single facet of a user's health (fitness, prescription medications, test results, discrete illness or injury, etc.), the BSA system of the present invention provides a holistic approach that engages the user in interaction on a frequent basis over time. In one embodiment, the system provides a graphical, voice-enabled and touch and text-based user interface on mobile as well as desktop and other online platforms, aided by a natural language engine and back-end health expert system that guides users through a myriad of health concerns and queries. The system provides personalized suggestions relating to each user's personal health condition and wellness goals, as well as reminders of medical appointments and medication schedules and real-time notifications of location-specific general health concerns (such as the spread of an infectious disease in a user's geographic area).
• The system processes user voice and text input and queries and displays responses utilizing various media (voice, text, graphics, animation, video, etc.) that prompt users for additional information on an “as-needed” basis, rather than requiring users to fill out long forms and provide data that is not relevant at the time. Users provide proxies for external resources, such as pharmacies, labs, medical centers and retail providers of health-related goods and services. In one embodiment, the system notifies emergency contacts provided by users in the event of an emergency explicitly identified by a user or inferred from user interaction with the system (e.g., data from a wearable heart monitor).
• User profiles are maintained and updated dynamically, and are available to users on a secure basis at all times. A frequent “active check-in” process enables the system to monitor user health by listening to, recording and categorizing any health-related information users provide. Such information includes daily replies to check-in prompts (e.g., “How did you sleep last night?” or “How is the pain in your neck?”), volunteered symptoms (e.g., “My arm hurts.” with intelligent dialogue follow-up such as “What part of your arm?” to better identify the problematic location or “Are you experiencing numbness and/or tingling in your arm?” to identify nerve or vascular damage) and other health status factors relevant to their physical and mental state, as well as information obtained from wearable and other user monitors and other external sources (via user proxies where necessary—e.g., lab results following a blood test), including, for example, data mining of queries and other user inputs into Google, Facebook and various other websites or applications.
• The system provides personalized responses, utilizing its expert system and user profiles (including external data), as well as aggregate third-party data. In one embodiment, the system provides an immediate response upon detecting a trend or concern based on information provided by a user. Such a response might include a recommendation to contact a particular doctor, a warning to avoid certain behavior, or a follow-up question regarding other potential symptoms. Less time-sensitive personalized recommendations include providers of health-related goods and services (including medical specialists) as well as “best practices” relating, for example, to particular medications, nutritional supplements, food, or fitness schedules. The expert system “learns” over time, providing more accurate and personalized information as a result of increasing experience with individual users and correlation of aggregate user and other external data over time.
• In another embodiment, the system maintains a personalized calendar and diary based on various user data relating, for example, to monitored symptoms, diagnoses, exercise routines, medications, doctor appointments and other scheduled behaviors. The system employs this calendar to notify users when such events are imminent, and also to prompt users when a concern is detected (e.g., asking whether a daily medication was missed based on a recurring symptom).
• The system encourages continuing and active user participation via an engaging interface, including health-related and other games and content designed to inform, entertain and motivate users (and from which the system infers user interests). In addition, the system detects patterns and events (e.g., from analyzing and correlating user profiles, external data and general medical information) and dynamically generates anonymized wellness social networks and initiates connections among users implicated by such patterns and events (e.g., a group of users sharing a particular set of symptoms or medical condition, or an interest in a particular health-related subject). In one embodiment, the system also offers premium services, such as real-time online consultations with medical professionals or less immediate recommendations based on a remote review of a user's health profile.
BRIEF DESCRIPTION OF DRAWINGS
• FIG.1 is a block diagram illustrating an embodiment of a system architecture of the present invention.
• FIG.2 is a block diagram illustrating an embodiment of additional components of an input-processing module of the present invention.
• FIG.3 is a block diagram illustrating an embodiment of additional components of an output-processing module of the present invention.
• FIG.4 is a flow chart illustrating an embodiment of dynamic monitoring and follow-up of user symptoms facilitated by an expert system module of the present invention.
• FIG.5 is a flow chart illustrating an embodiment of a dynamic feed-back loop for providing certain benefits to user by a benefits module of the present invention.
• FIG.6 is a flow chart illustrating another embodiment of a dynamic feed-back loop for providing certain benefits to user by a benefits module of the present invention.
• FIG.7 is block diagram illustrating a dynamic feedback loop of the present invention between user behavior and economic benefits and other incentives.
• FIG.8 is a flow chart illustrating an embodiment of dynamic monitoring of user behavior and adjustment of benefits provided to said user in an attempt to encourage or reinforce desirable user behavior.
• FIG.9 is a flow chart illustrating an embodiment of an adaptive data collection process of the present invention.
• FIG.10 is a state diagram illustrating an embodiment of one scenario of an adaptive data collection process of the present invention in the context of a tachycardia event.
• FIG.11 is a state diagram illustrating an embodiment of one scenario of an adaptive data collection process of the present invention in the context of an outbreak of gastroenteritis.
DETAILED DESCRIPTION
• “Health” is generally defined and measured as a level of functional or metabolic efficiency of a living organism. In humans, it is a general condition of a person's body and mind. “Healthcare” involves the diagnosis, treatment and prevention of disease, illness, injury and other physical and mental impairments.
• Yet, healthcare has proven to be extraordinarily expensive and ineffective. Access to doctors and other medical professionals is often both time and cost prohibitive, and effective personalized preventive wellness techniques have proven elusive, even in our highly technological age, despite the existence of various “wellness incentive programs” offered by governments, insurers, private employers and other organizations to promote health, encourage healthy behavior and discourage unhealthy behavior.
• In accordance with the present invention, various embodiments of a novel architecture and methods are disclosed for a BSA system that continually over time monitors and analyzes user interaction, medical and financial behavior, as well as general wellness and lifestyle activities, and dynamically adjusts user benefits (including credit assessments and promotional discounts) based on such monitored data. Such personalized benefits are implemented as an integral part of a dynamic feedback mechanism that incentivizes continued user interaction with the BSA system, including user purchases of health-related goods and services. As a result, users are incentivized to actively participate in the process and thereby enhance their wellness while reducing their healthcare costs.
• FIG.1 illustrates an embodiment of a system architecture of aBSA system100 of the present invention (frequently referred to herein as the “system”). Users employvarious Client Devices110 to connect (in this embodiment, via the Internet150) to aBSA Server115 that functions as an ever-present user-friendly interactive behavioral support agent. In other embodiments, system components may be interconnected via LAN, WAN or other network connections. Even while users are not interacting withBSA server115 via theirClient Devices110,BSA Server115 may interact with variousExternal Data Sources160 to exchange information that can be employed in subsequent user interactions (with third-party organizations and physical devices as well as with BSA server115).
• It should be emphasized that the functionality embodied inBSA Server115 andClient Devices110 can be allocated among various different hardware and software components. For example,BSA Server115 could be implemented as a single server computer or as multiple interconnected computers. The connectivity among the various components ofBSA system100 can also vary in other embodiments. For example, certainExternal Data Sources160 may connect directly toClient Devices110, while others may connect toBSA Server115.
• Moreover, the distribution of “client-server” functionality betweenBSA Server115 andClient Devices110 can range from a “dumb client” implementation (in whichClient Devices110 merely display information and transmit user input to BSA Server115) to “smarter client” scenarios in which client applications or smartphone “apps” Implement some or all of the functionality ofBSA Server115 illustrated inFIG.1. Whether functionality is implemented in hardware or software, or in a client or server, is a design decision. The software components described herein (as well as user and other data) can be embodied in various physical storage media (i.e., memory), including non-transitory computer-accessible storage media.
• Client Devices110 can include server, desktop, laptop and mobile devices, such as smartphones, with various hardware peripherals, such as monitors and touchscreens, keyboards, mice and touchpads, wearable devices like smart-watches, among others. Software inClient Devices110 can include operating systems and applications, as well as smartphone “apps.” In one embodiment,Client Devices110 utilize a web browser client to communicate withBSA Server115, while other embodiments employ one or more smartphone apps. In another embodiment,Client Devices110 employ a user-friendly graphical, voice-enabled and touch and text-based interface that facilitates an engaging interactive experience, enhanced via a natural language engine, as discussed in greater detail below.
• Users ofClient Devices110 may utilize health-related wearable and other user monitoring devices to track various aspects of their health (heart rate, blood pressure, etc.). Such monitoring devices can, in other embodiments, be present on Client Devices110 (e.g., smartphone GPS, cameras and other hardware) and can communicate directly withBSA Server115. User Monitors160hare but one example of theExternal Data Sources160 that exchange information withBSA Server115 in the background, regardless of whether users are interacting withBSA server115 via theirClient Devices110. Examples of otherExternal Data Sources160 include Medical Centers160s(e.g., notes, schedules, diagnoses, billing and other information from hospitals, doctors' offices and outpatient treatment and surgical centers, among others),Labs160b(e.g., for blood tests, MRIs, etc.).Pharmacies160c(e.g., for prescription drug billing and other information, as well as other health-related products),insurance Companies160d(e.g., for policy, claim and billing information), Government Agencies160e(e.g., for medical benefit payments and related information),Retail Providers160f(e.g., information regarding health-related products and services from third-party retail websites and portals, as well as billing and payment information for such products and services), andExternal Websites160g(e.g., an external social network or a personalized website hosting an exercise regimen or other health-related information that is tracked externally but shared with BSA system100).
• These External Data Sources may be accessed via external “proxies” or standard Application Programming Interfaces (APIs) for exchanging information with software running on other devices, such as computers (e.g., BSA Server115) or smartphones (e.g., Client Devices110). Such external data may be “pushed” toBSA Server115 whenever an update occurs (e.g., when a prescription is refilled) or “pulled” byBSA Server115 via periodic polling (e.g., a daily check of a website for updated information).
• The components ofBSA Server115 can be roughly classified into three categories or layers of functionality. Note that this is a conceptual construct, and that certain functionality may be implemented across multiple of these layers, as well as multiple different computers or other devices, includingClient Devices110 in some embodiments.
• One such layer is theData Store120, which includes various databases for storing information that can be exchanged with other components ofBSA system100. In various embodiments data stored inData Store120 or used in any other part ofBSA system100 can include quantitative and qualitative attributes respectively or combinations thereof. In some embodiments, the quantitative attributes may be numerical or Boolean values. In some embodiments, qualitative attributes may be a categorization, or grade or a descriptive string. In various embodiments, the data can be used or stored in the form of arrays, lists, trees, graphs or tables, etc. respectively or as combinations thereof. In various embodiments the data can be stored in certain compressed and uncompressed forms or combinations thereof. In various embodiments all or portions of the data may be compressed using lossless or lossy compression algorithms respectively or using combinations thereof. In some embodiments lossless compression may be implemented via Lempel-Ziv algorithm or variations thereof. In other embodiments lossy compression may be implemented via various transform coding and quantization methods known in the art. One key database maintainsUser Profiles122, which include a vast array of personalized information specific to each user. In other embodiments, User Profiles122 may be implemented as multiple distinct but interconnected databases.
• User Profiles122 include standard medical profile data, such as name, age and other identifying information, as well as information relating to health insurance and doctors, medical history and credit history and so forth. In addition to this standard profile information, User Profiles122 may also include data relating to user interaction withBSA system100, as well as user-related data (individual and aggregate) fromExternal Data Sources160 that exchange information withBSA Server115.
• Such information includes direct “substantive” data from both External Data Sources160 (links and APIs, lab results, monitored fitness data, purchases of health-related goods and services, etc.) and from user interactions with BSA system100 (e.g. any combination of symptoms, health status, sleep patterns, activities performed, queries, medications, premium and other requested services, direct purchases of health-related goods and services, participation in social networks, games played etc.). In some embodiments, theBSA system100 would encourage regular reporting or check-in of symptoms and health status by users and such data is stored inUser Profiles122. In some embodiments, all user interaction withBSA system100 including check-in of symptoms is treated as an interactive process akin to a query, requiring responses and follow-up by both user andBSA system100 and the entire interaction is stored inUser Profiles122.
• User Profiles122 also include indirect “procedural” interaction data and metadata, such as the nature and frequency of interactions with bothBSA system100 and External Data Sources160 (e.g., number and frequency of purchases of health-related goods and services, frequency of active check-Ins or reporting of symptoms, number of queries posed, overall time and quality of interaction with games and other system components, specific games played and scores achieved, calendared data for medications and workout schedules, topics browsed and clicked on, participation with other users via system-generated social networks, etc.).
• Metadata generated by other components ofBSA system100 and stored inUser Profiles122 include benefits data (credit limits and interest rates, product and service discounts, and various multidimensional behavioral metrics) as well as aggregate data correlated from patterns detected across other users and third parties (e.g., potential diagnoses based on similar symptoms across a spectrum of other users or recent medical findings).
• In short, User Profiles122 include virtually all data collected and maintained byBSA system100 that is specific to each user, as well as various metrics and annotations derived from such data (collectively, as well as individually). User Profiles122 are updated dynamically on a continual basis as users interact withBSA system100 and as information is exchanged withExternal Data Sources160.
• Data Store120 also includes, in one embodiment, aMedical Knowledge Repository124 that constitutes a comprehensive collection of generic medical knowledge (not personalized to specific individuals) that can be analyzed by other components ofBSA system100 and used for a variety of purposes, such as updatingUser Profiles122 based on detected patterns among aggregate data and/or recent medical findings (e.g., side effects of medications), responding to specific user queries, alerting users to recent infectious outbreaks, among a variety of other functions. In another embodiment,External Data Sources160 include non-personalized generic medical data from various organizations and third-party websites that provide updates toBSA Server115 as new information is made available. In some embodiments,Medical Knowledge Repository124 could be internal to, external to, or some combination of internal/external toBSA system100.
• Another component ofData Store120 is User Correlation andGroup Data126, which includes aggregate data (generated and maintained byExpert System134 in one embodiment) containing detected patterns across subsets of users (as well as other third parties). In some embodiments such aggregate data is based on information maintained in other databases ofData Store120, such asMedical Knowledge Repository124 andUser Profiles122. For example,BSA system100 might detect (from an analysis of recent updates to User Profiles122), a pattern of symptoms reported by users between the ages of 50-60 from California and Arizona, which leads to a hypothesis (supported by general medical information maintained inMedical Knowledge Repository124, or relying upon patterns first detected by BSA system100) that an infectious disease, to which individuals of that age group are particularly susceptible, may be spreading in that area.BSA system100 estimates correlation or similarity among various data sets. For example, it estimates cross-correlation between one user's data with respect to other users' data. Correlation or similarity can be estimated by various statistical means. In one embodiment, this can be estimated using correlation coefficients. In other embodiments, data clustering methods may be used to discover similarities among data sets. For example, various embodiments may use methods such as the k-means algorithm or tree builders or neighborhood growers or various combinations of these and similar algorithms. In some embodiments, principal component analysis (PCA) could be used to identify the most significant variables in the data as a pre-processing step before correlations are computed. By means of data clustering, groups of similar users can be identified, formed and maintained by theBSA system100.
• Information relating to these correlations among aggregate data is maintained and updated dynamically in User Correlation andGroup Data126, which is utilized byExpert System134 to generate updates toUser Profiles122 andMedical Knowledge Repository124, as well as Output140bto users. Updates toUser Profile122 may include annotations for future use such as potential caution if user starts certain new medications that may have adverse effects based on their existing profile data. Updates toMedical Knowledge Repository124 may similarly include information on heretofore unknown or unreported drug-drug or drug-food interactions, or adverse or beneficial effects of medications, supplements, therapies etc. based on user reported outcomes and depending on particular health or lifestyle characteristics. Updates to Output140bmay for example be an alert targeted at a subset of potentially affected users. In one embodiment, a more limited subset of users may receive more detailed and personalized alerts (e.g., based upon the specific symptoms they have already reported). Such alerts could include, for example, a more detailed analysis of a potential condition, a recommendation to contact a specific specialist doctor (or a user's personal doctor(s) stored in User Profiles122), a connection to other users with similar symptoms to facilitate sharing of information and possible treatments as well as recommendations for preventive or therapeutic actions (e.g., icing your knee, refraining from strenuous activity or using a particular drug or product). Various other patterns and correlations of aggregate data (e.g., potentially dangerous side effects of a particular drug or combination of drugs, or effective treatments, products or services) are made possible by the availability of dynamically updated detailed health profiles. Moreover, the accuracy, scope and overall value of these correlations improves as more users interact more frequently withBSA system100 over time.
• The processing and analysis of the data maintained inData Store120 is performed by theAnalytics130 layer of functionality inBSA Server115. As noted above, these layers may be combined or further segmented, the data may be pushed or pulled by various layers ofBSA Server115, and some or all of this functionality can, in other embodiments, be performed byClient Devices110.
• Benefits Engine132 (explained in greater detail below with reference toFIG.7) implements a dynamic feedback mechanism which is driven by user interaction withBSA system100 and withExternal Data Sources160.BSA system100 monitors these interactive and data update “events” (relying upon and updatingData Store120 as necessary) and provides them toBenefits Engine132 which quantifies them and dynamically generates various personalized user benefits (credit, discounts, etc.), which in turn incentivize users to increase the nature and scope of their level of interaction withBSA system100. In some instances such interaction may maintain or improve the user's wellness.
• Users are incentivized by the benefits provided byBenefits Engine132 to finance and purchase health-related goods and services via their user accounts (in some cases discounted for all or a selected subset of users, goods and services), and to interact withBSA system100 more extensively, e.g., providing daily check-ins, initiating more queries and following resulting suggestions. This continued interaction is then fed back toBenefits Engine132 to complete the feedback loop and generate further user benefits. As a result, users are guided toward behavior that enhances their usage ofBSA system100, and in some embodiments enhances their participation in their own wellness, while reducing healthcare costs.
• The manner in which these interactive and data update events are monitored byBSA system100 is explained in greater detail below with respect toFIGS.2 and3. The detailed operation ofBenefits Engine132, including the generation and quantification of multidimensional metric values, and transformation into specific assessments of credit, discounts and other personalized user benefits, is described below with reference toFIG.7.
• AnotherAnalytics130 component isExpert System134, which is responsible for much of the intelligence underlying the interactive behavior ofBSA system100, and in particular for facilitating medical diagnoses. In someembodiments Expert System134 andBenefits Engine132 may be combined into one module.Expert System134 relies upon (and maintains) dynamically updated information inData Store120 to perform various functions, such as responding to user queries, detecting and correlating patterns among aggregate data which are employed to generate user suggestions and alerts, and engaging in “Intelligent” interactions with users that (due to the extensive amount of personalized and aggregate data available to Expert System134) go beyond merely simulating a conversation with a medical professional. In some embodiments,Expert System134 is implemented as a rules-based expert system where the rules are defined by one or more domain experts (e.g. medical doctors). In some embodiments, the rules may be based on the certainty factor model (Shortliffe and Buchanan, A model of inexact reasoning in medicine, Mathematical Biosciences, Vol. 23, 1975, pp. 351-379). In another embodiment, the rules may be implemented as a belief network involving probabilities. In some embodiments, the certainty factors or probabilities associated with the rules are adjusted or refined dynamically. In some embodiments, the dynamic refinement also includes a feedback mechanism. In some embodiments, the feedback mechanism involves a domain expert. In some embodiments, the domain expert could be one or more medical doctors, or medical informatics specialists. In some embodiments, the feedback mechanism could involve analysis of real data obtained from users or from reliable medical knowledge resources. In various embodiments, the rules may be evaluated by one or more methods such as forward chaining, or backward chaining, or various other methods of reasoning known to someone skilled in the art. In some embodiments, themedical knowledge repository124 is integrated with theexpert system134. In some embodiments, the user correlation andgroup data126 are part of the expert system. In some embodiments, the user outcomes can be used to update the medical knowledge repository and in turn the expert system. It should be noted thatExpert System134 is, in one embodiment, a “learning” system in that its capabilities are expected to improve over time as more information is obtained from more users on a consistent (and perhaps more frequent) basis. In some embodiments, it employs machine learning techniques (sometimes referred to herein as a “learning engine”) that are implemented by supervised methods such as various classifiers (e.g., nearest-neighbor, Bayesian, regression, support vector machines, decision trees, rule-based, artificial neural networks, etc.). In other embodiments, machine learning is implemented by unsupervised methods such as clustering. In other embodiments,Benefits Engine132 andExpert System134 can be integrated into a single physical or conceptual module. In some embodiments, machine learning is employed to dynamically refine the probabilities and certainty factors associated with the rules.
• In one embodiment,Query Processor136 parses and analyzes user queries and converts them into a format compatible withExpert System134 and prepares and provides responses via Output140b. In other embodiments, the functionality ofQuery Processor136 is subsumed inExpert System134. In yet other embodiments theQuery Processor136 or theExpert System134 or portions thereof may be contained inClient Devices110, which communicate as necessary with various parts ofBSA Server115.
• In any event, certain queries (e.g., “What is diabetes?”) are categorized byExpert System134 as a “general information” question requiring a simple lookup for general medical information stored inMedical Knowledge Repository124 or external websites and databases, while other queries (e.g., “Why does my arm hurt after exercise?”) are categorized (also via Expert System134) as a “symptom-related” question, possibly resulting in anExpert System134 follow-up question or graphic display seeking additional user input, e.g., identifying the part of the arm that hurts and specific conditions under which the symptom is triggered.Expert System134 is also invoked to analyze the user's prior medical history, stored inUser Profiles122, which in turn might lead to various requests for additional information before generating a personalized response (possible diagnosis, suggestion to see a particular doctor, etc.). These queries and responses are, in one embodiment, stored inUser Profiles122.
• In one embodiment, direct interactions with users are implemented in a distinct I/O140 layer, which provides an interface between users and other layers ofBSA Server115. In one embodiment, I/O140 modules communicate directly withAnalytics130 modules, which read and writeData Store120 databases. In another embodiment, I/O140 modules access bothAnalytics130 modules andData Store120 databases directly.
• The functionality of I/O140 modules is explained in greater detail below with reference toFIGS.2 and3. As a conceptual matter, these modules handle both input140afrom users and Output140bto users, employing various media (voice, text, graphics, animation, video, etc.). In one embodiment, however, I/O140 modules are designed to implement highly interactive “conversations” that result In a great deal of overlap between input and output functionality.
• In one embodiment, I/O140 modules are the conduit through whichBSA Server115 interacts with users to implement a variety of different scenarios and provide various user services, including (among others):
• • Guiding users through their health concerns during frequent (e.g., daily) check-ins that may involve any combination of speech, typed text and graphical prompts (e.g., figures) for identifying symptoms and general physical and mental health status, as well as responses to and recommendations regarding user queries relating to medical conditions, fitness, nutrition, etc.
  • Monitoring users' direct and indirect behavioral interactions with the system, for use in providing a vast array of personalized user services, including those requiring correlations among aggregate user data
  • Dynamically updating personalized user profiles including, for example, standard profile information, emergency and close family contacts, monitored behavioral interactions with the system and connections to users' external data sources (e.g., doctors, labs, pharmacies, insurance companies, wearable and other monitoring devices, GPS, etc.) via standard proxies and APIs with user-provided authentication credentials
  • Providing personalized “best practices” treatment, nutrition and general healthcare suggestions to address specific user health issues and wellness goals (and including, for example, localized suggestions using GPS coordinates to recommend nearby health-related facilities)
  • Reminding users of their medication schedules, medical appointments, and other calendared items, generating and maintaining a user calendar automatically based on direct and indirect user interactions with the system
  • Generating and maintaining automatically personalized user diaries (e.g., of user exercise and other health-related routines) based on direct and indirect user interactions with the system
  • Providing custom user alerts based on “real-time intelligence” (as well as location, weather and other environmental factors) regarding emergencies and related health events, such as the spread of a local infectious outbreak (in some cases relying upon users' current GPS coordinates), as well as personalized suggestions requiring, for example, a potential doctor visit
  • Dynamically generating personalized and anonymized wellness social networks targeted at specific users sharing, for example, a particular set of symptoms or medical condition, or an interest in a particular medical subject or wellness goal (allowing group postings, real-time text and chat, and direct voice interaction, among other services)
  • Recommending medical specialists for user consultations
  • Providing Instant and secure access to user medical records, including medical history, lab work, vaccinations, etc.
  • Offering premium paid services to users including, for example, real-time responses to health-related queries by medical professionals, or suggestions within a specific timeframe based on a remote review of health concerns by medical professionals
  • Offering personalized credit financing for user purchases of health-related goods and services, based on their direct and indirect behavioral interactions with the system
  • Offering personalized individual and group discounts and other promotions regarding user purchases of specific health-related goods and services, based on their direct and indirect behavioral interactions with the system (Including, for example, providing anonymized health details for aggregate correlation
  • Providing an engaging graphical, voice-enabled and touch and text-based user interface (supported by an intelligent back-end including an expert system that “learns” as more data is obtained over time) that includes games and other content to inform, educate and entertain users, as well as motivate them to continue to participate in further system interaction
• User Input140aInclude data update events fromExternal Data Sources160, such as lab test results, prescription medication notifications, electronic receipts from retailers regarding purchases of health-related goods and services, user monitor data (e.g., results from a daily exercise routine, places visited, distance traveled, heart rate and blood pressure or blood sugar data), and a wide variety of other types of data updates. Note that such data updates include not only externally-initiated events, but may also come in response to information queries initiated byother BSA Server115 modules (e.g., a request for data from a heart monitor initiated byExpert System134 in an effort to respond to a user-initiated query).
• Other examples of user input140ainclude user queries and user responses, health status information and symptoms revealed during daily and ad hoc check-ins, and various other user interactions, such as browsing content, playing games, and participating in social conversations, as well as information collected directly fromClient Devices110 with or without active user participation. Virtually all such user input140ais monitored (as discussed in greater detail below) and stored in User Profiles122 (e.g., for use in calculating personalized user benefits, such as credit and discounts), including metadata relating to the information provided, such as classifications of the type of information provided, time and frequency of particular types of interactions, among other metadata.
• User Output140b, which is also monitored, includes personalized information generated byBSA Server115 for users. Examples of such user Output140binclude responses to user queries and follow-up requests for additional information, general messages, product suggestions, specialist recommendations, alerts, reminders and other information presented to users employing various formats and media.
• Turning toFIG.2, block diagram200 explores one embodiment of the input-processing functionality performed by BSA Server115 (fromFIG.1) in greater detail, illustrating various key components. As noted above, this separation of input and output modules is conceptual, as there is a great deal of implementation overlap between input and output functionality.
• Input-processing module240a(140afromFIG.1) obtains information, in one embodiment, via internet250 (150 fromFIG.1), from both External Data Sources260 (160 fromFIG.1) and Client Devices210 (110 fromFIG.1), and relies uponother BSA Server115 modules, such as the various Analytics230 (130 fromFIG.1) modules and Data Store220 (120 fromFIG.1), to analyze and store this information. Various proxies and APIs, such as User Monitor Interfaces241 andExternal Data Proxies242, are employed to obtain information fromExternal Data Sources260. They then provide this external data toEvent Monitor248, as explained in greater detail below.
• Other input events—i.e., user input obtained directly from users interacting withBSA system100 via theirClient Devices210—require additional processing before being provided toEvent Monitor248. Such user input events are processed initially byUI Event Handier243 which, in one embodiment, classifies these events into three categories.
• UI Event Handier243 employsSpeech Detector244 to identify speech events (i.e., user voice input), which it then provides to Speech-to-Text Converter245, which converts that user voice input into text, which it then provides toNatural Language Parser246. Remaining non-speech events fall into two categories—i.e., keyboard input (i.e., text) and other events, such as mouse or touch events.
• UI Event Handier243 provides these other (non-speech, non-text) events directly toEvent Monitor248, while providing the remaining non-speech text events toNatural Language parser246, which parses the text (whether or not originally converted from user voice input), in one embodiment into a variety of distinct types of events before providing them toEvent Monitor248. For example,Natural Language parser246 employs, in one embodiment, aQuery Detector247 to identify one of these event types as “queries”, which are then provided toEvent Monitor248. Other non-query event types (e.g., query responses by users, symptoms, health status events, etc.) are separately provided toEvent Monitor248. In other embodiments, this functionality of identifying, classifying and processing distinct event types, can be performed byEvent Monitor248, orvarious Analytics230 modules onBSA Server115.
• In one embodiment,Event Monitor248, upon receiving these various different types of user input events originating fromExternal Data Sources260 andClient Devices210, employsvarious Analytics230 modules onBSA Server115 to further process these events. In otherembodiments Event Monitor248, upon receiving these various different types of user input events may write them directly to Data Store220 (120 inFIG.1). In other embodiments, some or all of this analysis can be performed entirely onClient Devices210 or on other modules ofBSA Server115.
• In any event, such analysis, as noted above, may result in a variety of different actions including formulation of immediate responses to user queries, including follow-up queries to users, dynamic modifications ofUser Profiles122, recommendations of potential user actions, such as visit to a particular doctor, dynamic generation of a social network connecting specific users, and a host of other actions and “outputs” (discussed inFIG.3 below). For example, in one embodiment, upon detecting patterns, events or other issues based on correlations among the user and other internal and external data,Expert System134 prompts users with relevant queries and continues to follow up with users over time, eliciting relevant data until such issues are deemed resolved.
• In the course of performing this analysis, these user input events, sometimes in combination, are classified into various different categories, including (among others):
• • Data from User Monitors and related devices
  • Visits to Doctors, Labs, Pharmacies, Retailers, Affiliated Websites, etc.
  • Contractual health-related information from insurance companies, Government Agencies, etc.
  • Queries
  • Reports of Symptoms, Health Status, Nutrition and Exercise regimens, etc.
  • Interactions with other users and third parties (e.g., internal and external Social Networks)
  • Games-related data
  • Purchases (internally and externally) of health-related goods and services via user accounts
  • Metadata relating to various user interactions regarding the nature and frequency of user input events (e.g., number and frequency of check-ins, time spent browsing particular content, number and types of symptoms or health status reports, and various other types of metadata)
• Turning toFIG.3, block diagram300 explores one embodiment of the output-processing functionality performed byBSA Server115 in greater detail, illustrating various components. As noted above, in one embodiment, Output-processing module340b(140bfromFIG.1) receives different types of output events, via Event Monitor348 (248 fromFIG.2) generated by various Analytics330 (230 fromFIGS.2 and130 fromFIG.1) modules onBSA Server115, relying upon Data Store320 (220 fromFIGS.2 and120 fromFIG.1).
• In one embodiment, such output events are ultimately communicated, via internet350 (250 fromFIGS.2 and150 fromFIG.1) to both External Data Sources360 (e.g., ordering a prescription refill) and Client Devices310 (e.g., responding to a user query or other input, or initiated by BSA Server115). Initially, however, such output events (in one embodiment) are forwarded to and processed byEvent Monitor348.
• For example, feedback generated for user monitors (e.g., to initiate an immediate heart rate test) is forwarded to the appropriate device via User Monitor Interfaces341 (241 fromFIG.2). External data updates (e.g., ordering a prescription refill, requesting a doctor appointment, etc.) are forwarded to External Data Proxies342 (External Data Proxies242 fromFIG.2) for transmission to the appropriate one of the External Data Sources360 (260 fromFIGS.2 and160 fromFIG.1).
• Remaining output events, however, may require additional processing before being provided to users via their Client Devices310 (210 fromFIGS.2 and110 fromFIG.1). Note that such output events may be presented to users employing various different media (text, speech, graphics, animation, video, etc.).
• For example, textual and spoken output is first processed by Natural Language Generator346 (same module, in one embodiment, asNatural Language parser246 fromFIG.2), which converts the output event into a natural-language textual message (e.g., “I think you should make an appointment with your orthopedist, Dr. Smith”). That textual message can be forwarded directly to UI Event Generator343 (for display to users via their Client Devices310), or first converted to speech, via Text-to-Speech Converter345 (same module, in one embodiment, as Speech-to-Text Converter245 inFIG.2), and then forwarded to UI Event Generator343 (same module, in one embodiment, asUI Event Handler243 fromFIG.2) for delivery to users via the speakers ofClient Devices310. In one embodiment, natural language output is delivered to users as both speech and text. In some embodiments, all of these processing tasks may be performed byAnalytics Module330 or other modules ofBSA Server115.
• To illustrate the type of interactive communication afforded byBSA system100, consider the following scenarios of daily user “check-ins” in which all interaction is recorded (including, for example, time and date) and logged in User Profiles122:
Scenario 1
• • [User] “My knee is hurting”
  • [System] “Which knee?”
  • [User] ‘The right’
  • [System] “When did it start?”
  • [User] “Bothering me since this morning”
  • [System] “How did you injure it?”
  • [User] “Don't remember”
  • [System] “You were at the bowling alley last night. Do you think you sprained it there?”
  • [User] “I think so”
  • [System] “Is there any swelling in the knee?”
  • [User] “Yes”
  • [System] “Is it wobbly and moving from side to side?”
  • [User] “Yes”
  • [System] “You need to see Dr. Smith. I'll connect you to make an appointment.”
Scenario 2
• • [User] “I am feeling lightheaded”
  • [System] “Did you eat an apple with your NewBPDrug?”
  • [User] “Yes”
  • [System] “Many patients are seeing the same symptoms. It seems to pass after about 20 minutes. I'll send a note to your doctor. Next time remember not to eat an apple with your NewBPDrug. Let's talk again in 20 minutes.”
  • [System] [20 minutes later; if no check-in from user] “Are you still feeling lightheaded?”
  • [User] “Much better but not fully gone.”
  • [System] “That's a good sign. Let's check again in 15 minutes”
  • [System] [15 minutes later; if no check-in from user] “Are you still lightheaded?”
  • [User] “No”
  • [System] “I'll make a note that it may take you longer than usual to recover from the symptoms.”
• This iteration of input and output events illustrated inFIGS.2 and3 forms the basis for the various types of personalized interactions betweenBSA Server115 and both users (via their Client Devices310) and theirExternal Data Sources360. As noted above, virtually all of these personalized interactions are monitored (byEvent Monitor248 inFIG.2 for input events, illustrated asEvent Monitor348 inFIG.3 for output events) for use by various other components ofBSA system100.
• FIG.4 illustrates one embodiment of aprocess400 in whichBSA system100 determines, as information is received relating to a user's medical condition, that a follow-up course of action is warranted. For example,BSA system100 may prompt the user with additional queries, recommend additional tests, suggest that the user contact a specialist, or pursue various other courses of action warranted by the vast array of information made available toBSA system100 from the user, as well as from other users and third-party data sources.
• In this embodiment, at any given point in time (e.g., during a daily check-In), a user providesBSA system100, instep410, with information, such as a particular symptom. Alternatively,BSA system100 may receive data (e.g., a lab result) fromExternal Data Sources160. In any event, such information is eventually processed byExpert System134, which determines, in step412, whether a follow-up course of action is warranted.
• In most situations, no follow-up is necessary, and the information is simply recorded in Data Store120 (including User Profiles122), at whichpoint process400 terminates. Note, however, thatprocess400 resumes eachtime BSA system100 receives information from users, whether directly or indirectly viaExternal Data Sources160.
• Whenever a follow-up course of action is warranted in step412, thenExpert System134 determines, instep416, whether requests for additional information from the user (whether via direct queries and/or prompts, or indirect access to External Data Sources160) will be sufficient, or whether additional tests or referral to a doctor or other healthcare provider are also required.
• If additional user information will be sufficient,BSA system100, in step420, queries the user directly (e.g., prompting for additional status on reported symptoms over a particular period of time) and/or pollsExternal Data Sources160 for additional information (e.g., monitoring the user's blood pressure over time). Upon receiving such additional information,process400 returns to step412 for reevaluation byExpert System134. Note that this “loop” may repeat for multiple iterations, in some cases requiring additional information from users, and in others requiring additional tests or medical intervention.
• IfExpert System134 determines, instep416, that additional tests or medical intervention are needed, then such recommendations are communicated to the user instep418 and recorded in Data Store120 (including User Profiles122). In this case, however,process400 does not necessarily terminate. Additional information from the user may also be required in step420. For example,BSA system100 may, in addition to recommending that the user contact a particular specialist, also prompt the user for additional information regarding related symptoms. In any event,process400 may eventually resume, atstep410, after the user follows up with particular recommendations and, for example, receives test results and other Information such as notes from a doctor.
• As is apparent from the above description ofFIG.4,process400 is an ongoing process designed to “intervene” (with recommendations to users or prompts for additional information) wheneverExpert System134 deems that an additional follow-up course of actions is warranted. Though involved in this process by providing Information (e.g., via daily check-ins and indirectly via External Data Sources160), users need not initiate the process, and in many cases will not even be aware that such intervention is warranted until prompted byBSA system100.
• FIG.5 illustrates one embodiment of a process500 in whichBSA system100 motivates and encourages users to use the system via changes in awarding points (including subtracting as well as adding points). In one embodiment, this functionality is implemented viaBenefits Engine132 inFIG.1.
• In one embodiment, module520 (as an example aspect of modules further described in780 inFIG.7) receives and stores all user symptoms and other information provided during check-in events over a given time period (e.g., daily) directly fromuser510 viaEvent Monitor248 ofFIG.2 (348 inFIGS.3 and748 inFIG.7), while in another embodiment module520 may retrieve this data from User Profile122 (and in another embodiment fromExternal Date Sources160 with or without any active participation by the user) inFIG.1, and subsequently makes this data available tomodule530.
• In one embodiment, inmodule530, the number of symptom check-ins over a given time period (e.g., one week) may be recorded as a quantified user-related data variable x₁(as an example aspect of module(s) further described in784 ofFIG.7). Module570 utilizes a function (as an example of what is described below inBenefit Function785 ofFIG.7) that uses x₁(in some embodiments in combination with other user related data, some of which may be fromExternal Data Sources160 or other users' data) to calculate points to be awarded to user via module530 (such points may be one of the benefits as described in the benefits module790). In another embodiment, inmodule530, variable x₁may represent some user-related data from External Data Sources160 (for example, from wearable monitors) collected in module520 with or without active participation by the user. In some embodiments such points may be redeemable for specified discounts on products purchased via user accounts. These points motivate the user to continue checking in symptoms on a frequent basis. In other embodiments, such points may represent credit for purchases or other forms of financial incentives to the user. In yet other embodiments the points may not represent financial benefits. In some embodiments points may represent status among users. In one embodiment module540 (as an example aspect of module(s) further described inCompliance Behavior Monitor775 inFIGS.7 and875 inFIG.6) may receive and maintain historical record of x₁values and compare for instance the value of x₁from the current period (x₁^new) with that from the previous period (x₁^old) to determine if the increase in the number of symptom check-ins is above a certain threshold. If not, then module550 may modify the point assignment function in module570 to assign more points for a given number of symptom check-ins to motivate user to use the system. If the threshold in module540 is exceeded thenmodule560 may not modify the point assignment function in module570. In other embodiments the behavior ofmodules550 and560 may be different, even reversed to penalize the user for not using the system (e.g., by subtracting points previously awarded).
• As is apparent from the above description ofFIG.5, process500 is an ongoing process designed to “intervene” (by modifying points rewards to users) wheneverBenefits Engine132 deems that necessary. Though involved in this process by providing information (e.g., via symptom check-ins and usage), users need not initiate the process, and in many cases will be gently nudged by theBSA system100 towards increasing or maintaining usage of the system and in some embodiments towards modifying their behavior to achieve desired system-wide as well as user specific goals and outcomes.
• FIG.6 provides yet another example of one embodiment of aprocess600 in whichBSA system100 utilizes itsBenefits Engine132 to motivate and encourage users to use the system and achieve better and more affordable healthcare outcomes. It should be noted that, in one embodiment (not shown), the activities of multiple users may be considered in awarding benefits. For example, a benefit may be awarded (to one or more users), or a benefit function may be modified, based upon the activities of one or more users, including detection of a trend evidenced by the activities of multiple users.
• In one embodiment, module620 (as an example aspect of modules further described in780 inFIG.7) receives and stores quantified record of purchases of a specific product during a given time period directly from theuser610 viaEvent Monitor248 ofFIG.2 (348 inFIGS.3 and748 inFIG.7) while in anotherembodiment module620 may retrieve this data fromUser Profile122 inFIG.1, while in anotherembodiment module620 may retrieve this data fromExternal Data Sources160 or other applications, and subsequently makes this data available tomodule630.
• In one embodiment, inmodule630, the number of purchases of a specific product (or service) during a period of three months, say, may be recorded as a quantified user related data variable, say x₁₉(as an example aspect of module(s) further described in784 ofFIG.7).Module680 utilizes a function (as an example of what is described below inBenefit Function785 ofFIG.7) that uses x₁₉(in some embodiments in combination with other user related data or other users' data) to calculate discounts to be awarded to user (via module690) for that specific product (such discounts may be one of the benefits as described in the Benefits module790). These discounts motivate the user to continue purchasing and using the product and possibly increase the frequency of purchase and usage. In one embodiment module640 (as an example aspect of module(s) further described inCompliance Behavior Monitor775 inFIGS.7 and875 inFIG.8) may receive and maintain historical record of x₁₉values and compare such values to facilitate decision making by the system (specifically process600 or theBenefits Engine132 inFIG.1,732 inFIG.7) regarding discount levels to be offered to user. If for instance, the product in question was not a first time purchase or there has been a repeated drop in purchase frequency thenmodule650 may be called upon to modifydiscount assignment function680 so as to decrease future discount assignment provided to the user as a way of discouraging drop in use of the product. Similarly, ifmodule640 determines that this Is a first time purchase of the product by the user or that this is the first time that there has been a drop in the user's purchase frequency for this product, thenmodule660 may be called upon to modifydiscount assignment function680 so as to increase future discount assignment provided to the user as a way of encouraging use of said product. In the event,module640 determines that users purchase activity does not fall under either of the two scenarios described above, thenmodule670 may be called to help make further decisions regarding discount levels. If the user has reached maximal discount levels that can be offered for this product byBSA system100 thenmodule675 may be called, which makes no modification to discountassignment function680. If however,module670 determines that maximal discount level has not been reached thenmodule660 may be called to modifydiscount assignment function680 to increase discounts as described earlier. In other embodiments the behavior ofmodules650 and660 may be different, even reversed in terms of increased or decreased future discount assignments.
• As is apparent from the above description ofFIG.6,process600 is an ongoing process designed to “intervene” (by providing and modifying specific product discounts to users) wheneverBenefits Engine132 deems that necessary. Though involved in this process by providing information (e.g., via specific product purchases), users need not initiate the process, and in many cases will be gently nudged by theBSA system100 towards modifying their behavior towards achieving desired system-wide as well as user specific goals and outcomes. It is also apparent that different users may have different products discounted to different levels.
• As described above, one component ofAnalytics130 ofFIG.1 is Benefits Engine732 (132 inFIG.1), illustrated in block diagram700 ofFIG.7. As noted above, in some embodiments, all user related data, i.e. direct and indirect Interactions of the user with the BSA System100 (which includes all user data from external sources) are stored inUser Profile122 inFIG.1 of Data Store720 (120 inFIG.1). In one embodiment Event Monitor748 (348 inFIGS.3 and248 inFIG.2) receives all such user related data (URD) and, in addition to sending them toData Store720, sends them to QuantifiedEvents780 ofBenefits Engine732. In another embodiment QuantifiedEvents780 periodically retrieves URD stored in User Profile ofData Store720. In yet other embodiments QuantifiedEvents780 receives Information from bothEvent Monitor748 andData Store720.
• In one embodiment illustrated inFIG.7,Event Quantifier782 of QuantifiedEvents module780 first interprets all the URD, and divides it into various different categories, where such categories may include (in other embodiments) various types of credit related information (e.g. income level, past payment and credit history with theBSA system100, FICO score etc., each considered a category), various types of general interactions (e.g. number of queries or check-ins in a given time period as for instance described inFIG.5, total time spent Interacting with the system, user-related data collected fromExternal Data Sources160, total amount of purchases, number of interactions with a specific social network, number of games played, types of geographic locations where user spends time as discerned from client devices etc., each considered a category) as well as dynamically generated additional categories (e.g. the number of purchases of a particular nutritional supplement in a given time period, number of visits to a specific provider etc.).Event Quantifier782 assigns quantified variables x₁, x₂, x₃, . . . to represent each of these categories or a combination of these categories. Such variables may or may not be numerical variables (e.g. they could be Boolean variables or a list of possible character strings, such as names of diseases). In one embodiment, the number of check-ins by a user during a week, an integer, could be assigned to x₁, for instance. The number of variables being assigned and tracked byEvent Quantifier780 is dynamically created for each user and can vary among users and also for the same user at different times. In one embodiment Quantified Events database784 may store a multidimensional array X=(x₁, x₂, x₃, . . . ) for individual users and in other embodiments the array X in784 may be stored in transient memory or inData Store720.
• Benefits module790 contains for each user a collection of benefits Y=(y₁, y₂, . . . ) that may vary from time to time. These variables y₁, y₂, . . . etc., each stand for a specific benefit, dynamically generated by Benefits module790, and may for instance be points redeemable, in some embodiments, towards discounts on purchases using the user accounts, interest rates, credit limits, may include user specific benefits such as discounts on a particular product or service etc., as for Instance described inFIG.6, and may also include non-financial benefits in the form of points, status, encouragement from theBSA system100 or collected from other users. In one embodiment Benefitsdatabase794 may store this multidimensional array Y=(y₁, y₂, y₃, . . . ) for individual users and in other embodiments the array Y in794 may be stored in transient memory or inData Store720 and Benefits module790 may retrieve such data fromData Store720 as needed. In one embodiment BenefitsReporter792 retrieves information from theBenefits database794 or its equivalent and provides the information to the user viaEvent Monitor748.Benefits Reporter792 may adjust the timing and format in which benefits are reported to users (e.g. hold reporting of benefits till certain number of them are collected up or till some special day on the user's calendar, or change a discount figure to a more user friendly form, such as that an item now costs half of what user paid for it before, etc.).
• Benefits Functions785 is a collection of functions F=(f₁, f₂, . . . etc.), one for each benefit y₁, y₂, . . . etc. in the Benefits module790. Benefit Function f₁takes the multidimensional array X from QuantifiedEvents module780 above for a given user and uses a specified formula to calculate a benefit y₁. Benefit Function f₂takes the multidimensional array X from QuantifiedEvents module780 above for same user and uses a possibly different formula to calculate a benefit y₂, etc. The functions f₁, f₂, . . . etc., i.e. the formulas that characterize the functions, are subject to change as needed as for instance described InFIG.8. An example of simple linear f₁and f₂could be as follows: f₁(X)=x₁w₁₁+x₂w₁₂+x₃w₁₃+ . . . . ; f₂(X)=x₁w₂₁+x₂w₂₂+x₃w₂₃+ . . . ; where w_ij(with i varying for each f_i, in this case between 1 and 2, and j varying between 1 and n if X has n components) are the weights assigned to the j-th component of X for purposes of calculating the i-th function f_i, and any of w_ij's may be zero. In various embodiments, other non-linear functions may be employed in an effort to best reflect a particular desired goal (e.g., providing increased credit limits to encourage increased user purchases). In some other embodiments, the functions employed inBenefits Function785 may be probabilistic in nature, such that output of such a function is non-deterministic, in that it is influenced by a probability distribution coupled with a random number generator.
• An additional element of theBenefits Engine732 is theCompliance Behavior Monitor775 that can dynamically modify the Benefits Functions785 to achieve certain desired user behavior outcomes as mentioned above. Initially the Benefits Functions785 may be set in some predetermined form by theBSA System100 but may be allowed to vary or evolve over time under the influence ofCompliance Behavior Monitor775. TheCompliance Behavior Monitor775 is described further with respect to the dynamic monitoring and benefit adjustment process800 ofFIG.8.
• Compliance Behavior Monitor875 (775 inFIG.7) compares changes In X. i.e. URD, which in turn relates to changes in user behavior and makes the determination whether certain functions f₁, f₂, . . . etc. of Benefits Functions88S (785 inFIG.7) should be modified so as to change benefits (e.g. increase the credit limit or lower the interest rate or provide specific product discounts) in order to encourage the user to increase or maintain the use of the BSA system. In some embodiments the benefits790 and Benefits Functions88S (785 inFIG.7) are dynamically determined by theExpert System134 with a view towards better outcomes for the user. An example of such dynamic adjustment of benefits is provided in the following paragraph. In one embodiment,Compliance Behavior Monitor875 maintains, as shown in876, an array HX of historical X values for each user starting from X^oldbeing the oldest through X^old+kbeing the newest, where k is a positive integer that is implementation dependent. In some embodiments, this array may be initialized to zero values at the beginning. New X values are retrieved as described in877, from Quantified Events880 (780 inFIG.7) and stored, as described in878, in the next available open position (i.e. all values are still in their initialized state, say zero) in the array. If there are no open positions, then data in X^old+1is used to overwrite data in X^oldand similarly all other entries in the HX array are shifted by 1 position such that the latest X can be written in X^old+k.Next module879 compares the trend among the historical X data, i.e. X^old+k, X^old+k−1, X^old+k−2. . . etc. For Instance, if a user's frequency of purchasing a certain product has decreased (as described inFIG.6) then this trend may be passed on to subsequent modules to initiate appropriate changes in the Benefits Functions885. In some embodiments,Compliance Behavior Monitor875 includes aLearning Engine881 which receives the trends in X frommodule879 and designs Benefits Functionsmodifications882, which are then implemented in Benefits Functions885. In some embodiments, theLearning Engine881 continues to review changes in X, changes in the trends of X etc. In response to its Benefits Functions modifications and continues to adapt its methods or algorithms for designing such modifications. (For example, inFIG.6 thedecision trees640,670 andrelated function modifications650,660,675 may be part of asimple Learning Engine881, where different types of function modifications are chosen in response to changing purchase data to arrive at optimal user response.) In some embodiments,Compliance Behavior Monitor875 may utilize URD from a plurality of users, and in some embodiments theCompliance Behavior Monitor875 may further utilize other external data fromMedical Knowledge Repository124 or User Correlation andGroup Data126. In some embodiments,Learning Engine881 may be implemented as part ofExpert System134.
• In an example of dynamic adjustment of benefits, an individual, with no significant past medical history, signs up as a user. This person is active and engaged, inputting data on a frequent and regular basis, disclosing poor health habits; the user eats unhealthily, and doesn't exercise. The system incentivizes the user to use the system and continue inputting data describing these habits by, for example, offering credit and finance terms for purchases of products and services of interest to the user. A few months later, the user has an annual physical exam with a physician. At this exam, it is noted that the user has an elevated body mass index leading to a diagnosis of obesity and elevated blood pressure leading to the diagnosis of hypertension. The physician orders standard laboratory tests; the user's glycolated hemoglobin (HbA1c) is elevated leading to a diagnosis of diabetes. Based on the results of the physical exam, laboratory test results, physician recommendations, and rules and information in theMedical Knowledge Repository124, theExpert System134 dynamically modifies benefits (in Benefits790 of theBenefits Engine132, or732 inFIG.7) to support better health outcome goals targeting body mass index, blood pressure, and diabetes. In one embodiment, theExpert System134 may take the physician's recommendation regarding the purchase of a blood pressure monitor and modify benefits to provide a discount and financing for said purchase. In another embodiment, theExpert System134 compares user's data against rules and information available inMedical Knowledge Repository124 and/or outcomes of other users (where such outcomes may be stored under user correlation andgroup data126 in some embodiments) to determine additional benefits to the user. For example,Expert System124 may provide discounts on a gym membership and subscription to Weight Watchers to counteract the user's obesity and discounts on a glucometer for his diabetes. In another embodiment, the system would offer benefits that incentivize the user to lose weight and be compliant with blood pressure medications.
• It should be noted that the functionality ofBenefits Engine732 may be allocated, in other embodiments, in virtually any manner amongEvent Monitor748,Compliance Behavior Monitor775, QuantifiedEvents780, Benefits Functions785, Benefits790, and other modules onBSA Server115 andClient Devices110 without departing from the spirit of this invention. Moreover, various different metrics and functions can be applied to this data in order to implement a feedback loop that assesses user credit, discounts and other benefits, provides such benefits to users, and continually monitors user behavioral interactions to determine the extent to which such metrics and functions should be modified to achieve desired system-wide and personalized user goals.
• Finally,Benefits Engine732 applies, in one embodiment, “user-wide” and “system-wide” constraints which result in modifications tocertain Benefits Functions785 based on constraints beyond monitored changes in relevant X values. For example, a limit to the amount of credit offered to any user (or particular users) may be desired. Moreover, such a constraint may be applied on a system-wide basis, resulting in a limit to the aggregate credit offered all users. Similar constraints on discounts and other benefits are also applied in this embodiment.
• In one embodiment, benefits “updates” are provided by theBenefits Reporter792 toEvent Monitor748 on a continual basis, while in other embodiments they are provided on a less frequent periodic or ad hoc basis. As noted above, users then modify their behavior based upon these various incentives, which in turn results in additional (or decreased) incentives asCompliance Behavior Monitor775 monitors each user's compliance—and this feedback loop continues indefinitely in an effort to encourage increased user participation withBSA system100, and in some embodiments increased user wellness, while reducing user healthcare costs.
• One embodiment of an adaptive data collection process of the present invention is illustrated inflow chart900 ofFIG.9, and further explored with respect to particular scenarios inFIGS.10 and11. Beginning withstep910, the system can be said to be in a “baseline” data collection state. In other words, as discussed above with reference to “User Interaction and External Data”Event Monitor348, the system continuously interacts with users and collects data from users as well as from variousExternal Data Sources160. In this “baseline” state, this includes, for example, daily check-ins in which users are asked for general information regarding their condition, sleep and eating patterns as well as any specific symptoms or ailments they may be experiencing and data from their wearable monitors or routinely scheduled doctor visits or lab tests. Users can, of course, also initiate such interaction at any time, notifying the system of specific symptoms they are experiencing as well as more general aspects of their current physical or mental condition (e.g., feeling happy or depressed).
• It should be noted that, at any given point in time, the system may be in a “Baseline” state with respect to one or more Individual users, while in other states (“Differential Diagnoses” states, “Treatment” states, etc., as discussed in greater detail below with reference toFIGS.10 and11) with respect to other users. As will be discussed below, such states will determine both the type and frequency of the system's adaptive data collection process.
• The system, instep912, with the assistance ofExpert System134, continually analyzes and correlates the data collected instep910 for each user and in some embodiments across all users. Instep914, the system assesses existing issues and determines, instep915, whether any follow-up actions are required. In other words (as will be explained in greater detail in the context of specific scenarios inFIGS.10 and11), the system identifies any “triggers” that may warrant further action with respect to an individual user or a group of users. For example, a user may report a particular symptom (e.g., chest pain) that, either immediately or over time, suggests a medical condition (severe or otherwise) that warrants further action in order to diagnose or treat that condition. Moreover, this information may also be obtained from variousExternal Data Sources160, such aswearable User Monitors160hor test results fromLabs160b. It is to be noted that the aforementioned “triggers” are based on data analysis. In one embodiment, the data analysis is based on decision criteria. In one embodiment, the decision criteria use a set of pre-defined thresholds. In another embodiment, the decision criteria is based on statistical analysis, wherein the statistical analysis includes, but is not limited to multivariate (e.g., z-score, chi-squared, etc.) or Bayesian (e.g., Bayesian risk) analysis. In another embodiment, the decision criteria could be based on the change in user's monitored date including but not limited to the nature and frequency of user events monitored by theBSA system100. In another embodiment, the decision criteria could be detection of change of user behavior regarding location tracking data. In another embodiment, the decision criteria could be detection of change in data associated with prescriptions, patient medical devices, or medical treatments. In one embodiment, the change in the monitored data could be associated with new location Information. In yet another embodiment, the change in user monitored data may be based on an observed change in user interactions with theBSA system100. In another embodiment, the decision criteria could be determined by theexpert system134. In another embodiment, the data analysis used to identify a trigger is performed by theexpert system134 using one or more of the rules-based or machine-learning embodiments already described. In another embodiment, the data analysis used to identify a trigger is performed by a dedicated module or engine implemented within theanalytics layer130 inFIG.1.
• In many cases,Expert System134, may determine that no further action is warranted, and, instep932, simply record the information inData Store120. If additional issues remain (as determined in step935), the system will return to step914 to assess such issues. Otherwise, it will return to step910—its “Baseline” state of data collection.
• If, however, the system determines that a particular issue warrants (and thus “triggers”) further action, then the system will, instep920, engage in a dialogue with one (or more) user(s), seeking to obtain additional information targeted to the specific trigger (e.g., symptoms of chest pain, dizziness, high blood pressure, diarrhea, etc.). As noted above, such triggers may be initiated by a user or may be prompted by the system, for example, based upon information obtained from External Data Sources160 (such as an external blood pressure/heart monitor, a physician's report or lab test results).
• In particular, the system seeks information quickly so that it can, instep922, perform any necessary “urgent” or “emergent” follow-up actions, such as recommending that one or more users visit a doctor or specialist, or even a hospital's emergency room (as well as facilitating any necessary appointments, doctor/hospital alerts, calling an ambulance, etc.).
• Instep930, the system begins to make adaptive adjustments to the type and/or frequency of its data collection process. For example, it may transition from general-purpose daily check-ins to a more targeted dialogue with one or more users, asking detailed questions relating to particular symptoms and/or triggers. In other words, the system may ask different “types” of questions in an effort to obtain more relevant data given the “trigger” of a particular symptom or other data warranting further action. Moreover, the system may also increase (and later decrease) the frequency with which it prompts users (e.g., reverting from general daily questions to hourly specific questions targeting a user's worsening symptoms and later, for example, decreasing to twice daily prompts as a user's symptoms begin to improve and eventually back to “baseline” daily prompts when the symptoms have resolved).
• Moreover, instep930, the system may also adjust the type and/or frequency of data collection viaexternal Data Sources160. For example, as will be discussed below, various wearable monitors may automatically collect and retain data at a particular frequency and resolution for a period of time and periodically report summary information to the system. But based upon particular triggers, the system may (again with assistance from Expert System134) modify the settings of aparticular User Monitor160h, both to adjust the type of data collected (e.g., collecting more finely-grained details or entirely different types of data) as well as the frequency with which such information is collected by the system (e.g., retrieving hourly blood-pressure readings, as opposed to daily peaks and lows).
• Such information is then recorded in Data Store120 (in step932), and a continuous process is performed, via determination instep935 as to whether the issue remains active, then throughstep914 to step915 as to required further follow-up action (perstep920 and involving type and frequency determined by step930), until such point as the situation is resolved (even if only temporarily), at which point the system returns to its baseline state of data collection Instep910. As noted above, these various states may apply, at any given time, only to a particular use only or group of users while the system is in a different state with respect to other users. It should be emphasized that the adaptive frequency changes discussed herein (in addition to changes to the type of data collected) are of great significance. For example, users would not tolerate high-frequency polling on a regular basis. Moreover, collecting and reporting such high-resolution data at high frequencies on a regular basis would quickly overwhelm the system as well as individual user monitors (storage, network bandwidth, etc.). It is therefore important that both the type and frequency of the collection of such data be adaptive, and thus be increased or decreased only when warranted.
• To appreciate the benefits of this adaptive data collection process illustrated inflow chart900, particular scenarios are explored below with reference toFIGS.10 and11.
• Turning toFIG.10, state diagram1000 illustrates a particular scenario of the adaptive data collection process discussed above with reference toFIG.9, involving an event of tachycardia (increased heart rate). In this scenario, the user is a middle-aged man with no prior medical history of heart-related problems who acquires a wearable heart monitor. The heart monitor need not be a dedicated heart-monitoring device and may well be a more general-purpose wearable device (e.g., a smartwatch) that monitors other activities (such as distance traveled, calories burned, sleep patterns, etc.) in addition to the user's heart rate. In one embodiment, the heart rate monitor may be able to detect not only the rate but also the specific heart rhythm.
• In this scenario, before the user experiences any symptoms, the system may be considered to be in a “Stage 1”Baseline state1010. This is the “normal” state of the system in which 1-2 daily check-in events are performed as discussed in greater detail above. The system prompts him on a daily basis to report any symptoms (which he may also report at any time), as well as general questions regarding the user's sleep and eating patterns, how the user is feeling, etc. In addition, in thisBaseline state1010, the user's heart monitor, which continuously monitors heart rate, reports average hourly heart rate to the system. In this scenario, for example, the heart monitor contains continuous “second-by-second” heart-rate data which is overwritten every week on the device; but the hourly heart-rate averages reported to the system are retained indefinitely (e.g., stored in Data Store120).
• At some point during thisnormal Baseline state1010, the user suddenly experiences shortness of breath and lightheadedness, which the user reports to the system (see “Stage 1 to Stage 2” Trigger1015). In addition, the heart monitor detects the user's elevated heart rate (e.g., exceeding a built-in threshold) and reports it to the system. In another embodiment, the system polls the heart monitor to collect the user's heart rate and determines, based upon a predefined threshold, that it is elevated. In any event, this combination of user-reported and device-reported information is interpreted by the system as aTrigger1015, causing it to transition to a “Stage 2” Differential Diagnoses state1020.
• In one embodiment,Expert System134 employs a rules-based learning engine that may involve a support vector machine to make these determinations and correlate this information (e.g., symptoms of shortness of breath and lightheadedness, coupled with an elevated heart rate) with a need for diagnostic follow-up (as discussed above with reference todecision step915 and follow-onsteps920 and922). Once in this Differential Diagnosesstate1020, the system modifies its data-collection process by adjusting the type and/or frequency of data collection (as discussed above with reference to step930).
• For example, in Differential Diagnoses state1020, the system extracts (and saves) from the heart monitor data at the finest grain resolution the heart monitor is capable of for as long as available in the buffer or for the hour preceding the sudden onset of the user's symptoms. With the assistance ofExpert System134, the system establishes an initial diagnosis of tachycardia. In one embodiment, where the monitor is able to diagnose the heart rhythm, the patient is diagnosed with “supraventricular tachycardia” (SVT). Based on this initial diagnosis, the system increases the frequency of the check-in process, from an hourly basis to every 10 minutes. Moreover, it prompts the user with more detailed questions targeted specifically at the user's new symptoms. For example, it requests a complete review of all the user's activities for the preceding 24 hours, including all food and beverages consumed (including water), as well as any medications the user took. The system identifies, for example, that the user recently began taking Sudafed, has been drinking a lot of coffee, and hardly consumed any food or water in the last day.
• The system also automatically modifies the type and frequency of information reported by the user's heart monitor by adjusting its settings remotely (e.g., via a WiFi or Bluetooth connection). For example, based on these adjustments, the heart monitor not only monitors and saves all data about the user's heart rate, it now also detects and generates data regarding the user's peak heart-rate readings, heart-rate variability and, in other embodiments, additional factors such as the user's breathing rate, temperature, etc. Instead of reporting only summary heart-rate averages, it now uploads all of this detailed information—at the finest resolution level the monitor is capable of—to the system on a more frequent basis—for example, every minute.
• Note that, while no additional steps were warranted based on the information compiled up to this point, the adjusted type and frequency of the monitoring and other aspects of data collection greatly enhances the likelihood that additional symptoms will be identified. As the already elevated heart rate continues to rise with worsening shortness of breath and lightheadedness, the system is notified promptly (see “Stage 2 to Stage 3” Trigger1025). For example, the heart monitor reveals this trend by automatically reporting more detailed data every minute. In one embodiment, the user notifies the system of the user's worsening symptoms by initiating contact, while in another embodiment the system prompts him for an update of symptoms during the now increased check-in process of every 5 minutes (or more frequently in other embodiments based on data from the monitor).
• As a result of “Stage 2 to Stage 3”Trigger1025, the system (once again with the assistance by the Expert System134) transitions to a “Stage 3”Treatment state1030, where it further modifies the type and frequency of its data-collection process. In this scenario, the system immediately notifies the user's physician, both to facilitate making an appointment and to provide the physician with the benefit of the specific data collected since the onset of the user's symptoms. The system continues to monitor the user, increasing the frequency of automated reports to every 15 seconds from the monitor while querying the user about symptoms every 5 minutes. Gradually the user's heart rate decreases (a fact which is conveyed to the system and automatically forwarded to the user's physician) and symptoms resolve.
• Without the system, the user would need to collect and maintain all of this information and remember to convey it to the user's physician, a manual process fraught with error. Moreover, without the benefit of targeted questioning in real time, the user would likely not know which information to convey to the user's physician and might not even remember (for example, that he took Sudafed) when prompted at the user's appointment (and likely only be prompted for some of this information, as compared to the thorough history compiled in real time by the system).
• Over time, as the user's symptoms begin to wane and the users heart rate begins to fall (see “Stage 3 to Stage 4” Trigger1035), the system (once again with the assistance of Expert System134) transitions to a “Stage 4” Maintenance state1040 (now several hours since the onset of the original symptoms). The system gradually decreases the frequency of check-ins from every 5 minutes to hourly, automated reporting from the user's heart monitor from every 15 seconds to every minute, and eventually to every hour (e.g., based on the user's improvement, as analyzed by Expert System134). The information conveyed from the users heart monitor is, in this embodiment, less detailed (i.e., summary in nature) in addition to being conveyed less frequently. Moreover, the “maintenance” questions are less detailed, essentially focused on the users progress with regard to his improving condition.
• As the user's symptoms gradually disappear over the next hours and the user's heart rate returns to normal (“Stage 4 to Stage 1” Trigger1045), the system transitions back to a “Stage 1”Baseline state1010, which may be a new baseline of frequency and type of check-in or returns to normal daily check-ins and summary average heart-rate reports from the user's heart monitor. From both the user and the system's perspectives, everything has returned to normal or a new normal. In a new normal, the system may check in with theuser 4 times daily rather than 1-2 times daily as before.
• However, two months later, the user experiences a recurrence of anothertachycardia event1050, with symptoms similar to, but more severe than, those discussed above regarding “Stage 1 to Stage 2” Trigger1015). In this scenario, due to the system's awareness of the prior event (recorded inData Store120, and accessed by Expert System134), the system enters yet another state (not shown), which results in him being immediately transported to the emergency room. The system forwards the detailed historical Information relating to the user's prior episode to the emergency room physicians. In this example, prior history of spontaneous resolution of supraventricular tachycardia (SVT), a specific rhythm identified by the user's heart monitor, within a 20 minute time frame enables treating physicians to avoid administering a drug called adenosine, thus avoiding its associated side effects.
• Turning toFIG.11, state diagram1100 illustrates another scenario of the adaptive data collection process discussed above with reference toFIG.9, involving an outbreak of gastroenteritis. In this scenario, a healthy thirty-year old woman with no history of medical problems has a wearable GPS monitor (e.g., of the type found in most smartphones on the market today).
• Before the user experiences any symptoms, the system may be considered to be in a “Stage 1”Baseline state1110 in which daily check-in events are performed, as discussed above with respect to the tachycardia scenario illustrated inFIG.10. In addition, in thisBaseline state1110, the user's GPS monitor continually tracks the user's detailed locations (overwritten every week) and reports summary information (in this scenario, the locations the user visited) to the system on a daily basis, which is stored inData Store120. In one embodiment, the system stores inData Store120 coarse location where that information could come from WiFi or cell towers or other time-delayed information stored on cell phones. In another embodiment, the system stores inData Store120 refined location utilizing real-time Information from actual GPS locator. In another embodiment, the system inData Store120 stores a combination of coarse and refined location.
• At some point during thisnormal Baseline state1110, the user suddenly experiences nausea, vomiting and diarrhea, which the user reports to the system. By analyzing the user's reported symptoms with the assistance of Expert System134 (see “Stage 1 to Stage 2” Trigger1115), the system transitions to “Stage 2” Differential Diagnoses state1120 to obtain additional data to address the user's symptoms.
• In this Differential Diagnosesstate1120, the system engages in a more detailed dialogue with the users (with the assistance of Expert System134) regarding issues targeting with the user's symptoms. It determines, for example, that the user's nausea and vomiting symptoms started the previous night, while the user's diarrhea started the next morning. The system learns that the users had eight recent watery, non-bloody bowel movements and that the user's experienced a little abdominal pain but no fever. The system also learns that nobody else in the users household experienced any of these symptoms.
• Initially, theExpert System134 obtains detailed Information from the user regarding food and beverages the user consumed over the past week. Note that this Information is collected as soon as possible as the user will likely remember less and less as time passes. The system also increases the frequency of check-ins from daily to hourly, and monitors the user's condition for any changes in the user's symptoms on this more frequent basis and may suggest the user consult a physician.
• The system also extracts the user's detailed GPS location data from the user's GPS monitor (where the most common GPS monitor would be the user's smartphone), effectively obtaining a list of locations the user visited over the past week, including trips to restaurants, grocery stores, sporting events, farmers markets, shopping malls, etc.
• The system (with the assistance ofExpert System134 and data stored in User Correlation and Group Data126), identifies other users in the user's area who also have wearable GPS monitors and automatically extracts detailed GPS location data from their GPS monitors. It adjusts the settings of their GPS monitors to begin reporting detailed location data on an hourly basis. These other users include, for example, the user's family, friends and co-workers, as well as those living within a certain radius of the user's home.
• When the user reports new symptoms—a fever and more severe abdominal pain—and the area-wide GPS monitor data Identifies Individuals who frequented the same establishments as the user did over the past week (see “Stage 2 to Stage 3” Trigger1125), the system (again with the assistance of Expert System134) begins to query those Individuals for the onset of similar symptoms. The system immediately sets up an appointment with the user's physician so that the user can obtain treatment as soon as possible. The system also relays all relevant symptom information to the user's physician. In another example and under other embodiments, when one or more additional users report similar gastrointestinal symptoms (“Stage 2 to Stage 3” Trigger1125), the system may initiate queries regarding gastrointestinal symptoms to all users in the area.
• When the system receives notification that a number of users (a number above some pre-determined threshold) are reporting similar gastrointestinal symptoms, it transitions to “Stage 3”Outbreak Identification state1130, notifying all users in the area (including those without GPS monitors) of a possible outbreak. It also increases the frequency of queries (now twice daily for unaffected users and hourly for affected users) to other individuals in the area for onset of similar symptoms. It also obtains more detailed information from them regarding the food and beverages they consumed over the past week. In another embodiment, the system may enterStage 3 after receiving lab test results from multiple users.
• When the system's analysis of the GPS monitor data from those users in the area begins to isolate potential stores or restaurants that could be the source of this outbreak (see “Stage 3 to Stage 4” Trigger1135), the system transitions to a “Stage 4”Containment state1140.
• In thisContainment state1140, the system notifies health officials of all affected users (at least those reporting similar gastrointestinal symptoms), and provides them with relevant information regarding this outbreak, as well as assisting affected users with setting up appointments with their physicians. By notifying the various physicians in advance of the symptoms, progression, and pertinent lab Information from other users, the physicians can more quickly narrow down the scope of their diagnoses and order more relevant targeted lab tests. For example, while diarrhea is often treated empirically (e.g., without performing stool tests), physicians notified of a possible outbreak will be more likely to order appropriate stool tests for microbiological evaluation. In this scenario, the lab results may confirm that these individuals were all Infected by the same organism.
• Continued statistical analysis of GPS monitor data, as well as more detailed information obtained from affected users, eventually isolates the source of the outbreak—a particular brand of meat sold by a grocery store in the area. The item is promptly removed from all stores selling this item. Area-wide GPS monitoring continues because additional users may still become symptomatic for some period of time. In one embodiment (not shown), an Infected user may Improve symptomatically only to self-inoculate and/or infect another, and the cycle begins again, requiring continued monitoring. When the offending item is removed, the source of the outbreak is gone, and symptoms gradually disappear leading to a transition period (see “Stage 4 to Stage 1” Trigger1145). When sufficient time has passed without any other users in the area reporting similar symptoms, the system returns to itsoriginal Baseline state1110, with normal daily check-in events and normal summary coarse grain location reporting from users with GPS monitors.
• It should be emphasized that the principles of the present invention are also applicable in various other embodiments outside of the healthcare sector. For example, in the food and beverage sector (restaurants, grocery stores, etc.), users could provide toBSA system100 restaurant usage data, menu choices, items they like and dislike, food sensitivities and subsequent possible food-borne illnesses, etc.BSA system100 could also collect this information by intelligent queries, as discussed above, as well as by location tracking (e.g., collecting eating habits at frequented restaurants).BSA system100 could offer credit and discounts for food/restaurant purchases, and analyze bills to collect some of the above-mentioned data. Offering benefits such as credits and discounts and other financial incentives encourage increased use of the system, and in turn allows theBSA system100 to collect valuable information on users.BSA system100 could utilize machine learning in itsExpert System134 to identify eating preferences, and could identify correlations among users with similar eating preferences and recommend new places to eat. It could also predict undesirable outcomes from certain restaurant or food choices and recommend against such choices. In these embodiments,Medical Repository124 would be replaced with a database of restaurant, menu, and food store data, whileExternal Data Sources160 would include postings by users regarding their food outings on other sites such as Facebook or user queries on Yelp. These scenarios could also apply equally to other lifestyle expenditures, such as travel or gadget purchases, as well as to video gamers where credit could be provided for game-related as well as in-game purchases.
• In other embodiments, the principles of the present invention are also applicable to the travel sector, in particular to flights. Users would provide desired flight data to BSA system100 (or the system could collect the data by intelligent queries), such as frequent flyer data, preferred airline, airports, etc. Machine learning techniques inExpert System134 could be employed, for example, to identify habitual flight patterns, and to learn, for example, if a user prefers “red-eye” flights or other types of flights or routes (including layovers on particular routes).BSA system100 could connect a user, via dynamically generated social networks, with other travelers with similar flying habits, and could correlate pertinent information gathered from other similarly situated travelers. Utilizing a process akin toFIG.6,BSA system100 could also provide special discounts on particular routes or flights that are personalized to individual users or groups of users, and could provide points, discounts, credit and other incentives to users based on their usage of the system
• In yet other embodiments, the principles of the present invention are also applicable to athletic conditioning. For example,BSA system100 could learn about athletes' training regimen, goals, training progress, etc. An expert system (trained by expert athletes and coaches) could be employed to guide athletes toward Improved training—e.g., detecting better training results in evenings than in mornings, and suggesting corresponding modifications to training regimens.BSA system100 could employ intelligent queries, for example, to learn about an athlete's recovery period, and could employ expert systems and machine-learning techniques to improve athletes' nutrition and supplementation, and to fine-tune their training schedules, set daily training goals and suggest rest periods, nutrition and supplement recommendations, massage therapy, etc. (e.g., to maximize off-season training benefits).
• For example, with respect to an upcoming competitive season,BSA system100 could tailor athletes' training regimens and help athletes prepare for competition. Based on results of competitions,BSA system100 would learn about the effectiveness of previous schedules and make corresponding adjustments.BSA system100 could set up social/athletic networks for the athlete users, and cross-correlate an athlete's data with data from other similarly-situated athletes, and use that information to enrich the system's knowledge base.BSA system100 could alert athletes of pertinent information regarding athletic venues for meets and other competitions, and provide information regarding predicted temperature, altitude or other forecasts.BSA system100 could also provide points and credit (as well as other benefits and incentives) based on their usage and compliance. Points, for example, could be used toward discounts for certain purchases—e.g., supplements, massages, dub memberships, etc. These purchases could also be financed by credit by theBSA System100.
• The present invention has been described herein with reference to specific embodiments as illustrated in the accompanying drawings. Many variations of the embodiments of the functional components and dynamic operation (including use-case scenarios) ofBSA system100 described above will be apparent to those skilled in the art without departing from the spirit of the present invention, including but not limited to different allocations of the hardware and software functionality ofBSA Server115 andClient Devices110 among one or more server, desktop, mobile or other computing devices, operating systems and firmware and software modules (including mobile smartphone apps and various networked online devices). Hardware and software functionality can be implemented interchangeably, and computer hardware can include peripherals such as monitors, keyboards, mice, trackpads and a variety of other peripheral I/O, user-wearable and other monitoring devices, including tangible memory and other storage devices (specifically non-transitory computer-accessible storage media in which data and software can be embodied). Moreover, the healthcare sector may be interpreted broadly (encompassing, for example, medicine, nutrition, nutraceuticals, cosmetics, fitness and lifestyle among others), and the functionality described herein may be applied outside of the healthcare sector without departing from the spirit of the present invention.

Claims (12)

1. A method for performing adaptive data collection to enhance the quality of data and efficiency of collection and utilization of data related to one or more users with accounts on a behavioral support agent system, the method comprising the following steps:

(a) collecting information from one or more users of the system on an ongoing basis during a first state,

wherein the information includes a first type of data collected at a first frequency;

(b) identifying a first set of triggers that warrant transitioning the system to a second state with respect to a subset of users,

wherein the first set of triggers is discerned in whole or in part from the information collected from the users in step (a);

(c) adjusting, during the second state, the type of information collected from the subset of users in step (b) by collecting a second type of data from the users,

wherein the second type of data differs from the first type of data and is targeted at a potential condition relating to the first set of triggers; and

(d) adjusting, during the second state, the frequency with which the second type of data is collected from the subset of users in step (b) to an adjusted frequency,

wherein the adjusted frequency differs from the first frequency.

2. The method ofclaim 1, wherein the first set of triggers includes symptoms evidencing a possible medical condition.

3. The method ofclaim 1, wherein the information is obtained both from users of the system and from external data sources.

4. The method ofclaim 1, wherein the first adjusted frequency with which information is collected from the first set of users is greater than the first baseline frequency, and is decreased in a third state to a second adjusted frequency below the first adjusted frequency but still above the first baseline frequency, and then returned to the first baseline frequency.

5. The method ofclaim 1, wherein the first set of users includes a plurality of users from whom information is collected during the second state.

6. A method comprising:

collecting, at a first frequency on an ongoing basis, a first type of data from at least one of one or mom users of a system;

identifying a first set of triggers corresponding to a subset of the one or mom users,

wherein the first set of triggers is determined in whole or in part from the first type of data,

collecting, at the first frequency, a second type of data from at least a first subset of the one or mom users,

wherein the second type of data differs from the first type of data, and

wherein the second type of data is targeted at a potential condition relating to the first set of triggers and

collecting, at a second frequency, the second type of data from at least a second subset of the one or more users,

wherein the second frequency differs from the first frequency.

7. The method ofclaim 6, wherein the first set of triggers comprises symptoms corresponding to a medical condition.

8. The method ofclaim 6, further comprising collecting, at the first frequency, the first type of data from an external data source,

9. The method ofclaim 6, wherein the first subset of users comprises a portion of the second subset of users.

10. The method ofclaim 6, wherein the first subset of users is a single user.

11. The method ofclaim 6, wherein the second subset of users is a single user.

12. An apparatus comprising:

a processor; and

a non-transitory computer-readable medium storing instructions operative, when executed by the processor, to cause the apparatus to:

collect, at a first frequency on an ongoing basis, a first type of data from at least one of one or more users of a system;

identify a first set of triggers corresponding to a subset of the one or mom users,

wherein the first set of triggers is determined in whole or in part from the first type of data;

collect, at the first frequency, a second type of data from at least a first subset of the one or mom users,

wherein the second type of data differs from the first type of data, and

wherein the second type of data is targeted at a potential condition relating to the first set of triggers; and

collect, at a second frequency, the second type of data from at least a second subset of the one or more users,

wherein the second frequency differs from the first frequency.

Images