HK1194508A - Location enabled food database - Google Patents

Description

Location enabled food database

Background

There is a strong need for those with special dietary needs, such as diabetics, to monitor and control their dietary and nutritional needs. As a practical matter, while understanding the need for tight control of their dietary needs, there are many obstacles that diabetics experience when attempting to control their food intake and the accompanying blood glucose levels. If not properly addressed, a number of serious health problems may occur. Accordingly, there is a need for improvements in the art.

Disclosure of Invention

It has been found that when a physician or other Health Care Provider (HCP) provides general health recommendations, such as guidance for weight loss, multiple exercises, etc., it is not sufficient to successfully achieve the desired results. However, when a physician provides a particular diet and/or exercise goal, the success rate of achieving that goal improves dramatically. For example, if a physician simply says "multi-exercise," the results are dramatically worse than if the patient is specified to run 5 miles per week. Likewise, patients are more likely to follow a dietary regimen that gives accurate dietary guidelines, such as a dietary regimen with specific calories, carbohydrates, and nutritional goals, than the general recommendation "eat less".

Even when specific health guidelines are provided, patients experience significant obstacles in determining whether the patient is in fact in compliance with the recommendations. Patients can become frustrated by the process of laboriously completing and collecting the large amounts of data needed to monitor compliance. In other words, the more steps that are consumed, the less likely it is that someone will enter the exact data if someone really wants to enter it. For example, there is a large amount of nutritional information available on the internet, but finding meal information that is suitable for a particular meal can also be feared at best. Patients often must struggle to complete a vast amount of information to receive the nutritional information they want. This burden plus time pressure reduces the likelihood that they will follow the prescribed schedule. Furthermore, even when patients find the correct information, they may know that the particular meal they intend to eat is not suitable for the prescribed meal, and as such, they are faced with the dilemma of either ignoring a meal plan by eating a meal anyway or following the plan but coping with the arduous task of finding an alternative meal that meets the goals of the meal.

The inventors of the present invention have developed a unique system and method that simplifies the process for entering meals and other information to determine compliance with prescribed meals. The system automatically filters, sorts, and/or highlights meal selection options based on the user's location, time of day (e.g., morning, lunch, etc.), meal demand, and/or historical meal preferences (e.g., favorite meals). This facilitates the entry of nutritional information as patients are only presented with information about their location and their dietary needs and preferences. For example, the system has the ability to customize the menu list based not only on location but also on time of day and rank the alternatives based on meal demand and historical selection. By ranking and refining menus and providing a short list that is customized to a particular user, information can be accurately and easily entered without requiring the user to traverse through multiple alternative choices that may be frustrating. If the available menu items do not meet the specific meal needs, the system may also suggest nearby establishments (such as other restaurants) with meals that meet the meal needs.

The system is also configured to provide a compliance metric that shows how well the user follows the meal based on the food identified as having been consumed. By doing so, the user can see their compliance trends over time and take corrective action to fix any problems if needed. Further, the health care provider may assess how well the user follows the dietary provision. The physician may also view physiological data (such as blood glucose levels, blood pressure, etc.) in order to monitor the health of the patient. If desired, the physician may modify the specific meal plan for the patient in order to improve the results.

In addition, the system integrates a food database with a structured test regimen. This combination of meal or food database and structured testing helped those dependent on meal intake (such as ACCU-CHEK 360 look-up evaluations and/or insulin to carbohydrate factor optimization). These structured tests rely on accurate knowledge of carbohydrate intake in order to effectively present reports for therapeutic optimization purposes. For example, if the patient or subject under test performed ACCU-CHEK 360 View evaluations and were at home ready to eat the same morning grain they eat each day, the system would show a favorite for that breakfast meal at the top of the list. After the object selects the favorites, information will be provided to the structured test for inclusion in the dataset. This helps to dramatically enhance the structured testing protocol by making it easier to enter more accurate meal information.

Other forms, objects, features, aspects, benefits, advantages, and embodiments of the present invention will become apparent from the detailed description and drawings provided herein.

Drawings

Fig. 1 shows a diagrammatic view of a meal compliance system according to one embodiment.

Fig. 2 is a block diagram of a portable device for use in the system of fig. 1.

Fig. 3 is a flow diagram of an overall technique for specifying a particular meal, capturing data, and reporting compliance.

Fig. 4 is a flow diagram illustrating a technique for selecting food items and providing compliance metrics.

Fig. 5 depicts a menu selection screen for a particular food location.

Fig. 6 shows a warning screen when a particular food location does not meet meal requirements.

Fig. 7 shows a data entry screen for entering health data.

Fig. 8 illustrates a first compliance report screen.

Fig. 9 shows a second compliance report screen.

Detailed Description

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Any alterations and further modifications in the described embodiments, and any further applications of the principles of the invention as described herein are contemplated as would normally occur to one skilled in the art to which the invention relates. One embodiment of the present invention is shown in great detail, although it will be apparent to those skilled in the relevant art that some features that are not relevant to the present invention may not be shown for the sake of clarity.

For the reader's convenience, it should be noted at the outset that the drawing in which an element is first introduced is generally indicated by the leftmost digit(s) in the corresponding reference number. For example, components identified with a one hundred series reference number (e.g., 100, 101, 102, 103, etc.) will generally be discussed first with reference to fig. 1, and components having a two hundred series reference number (e.g., 200, 201, 202, 203, etc.) will generally be discussed first with reference to fig. 2.

The dietary compliance systems and methods described and illustrated herein generally make it easier for users to comply with their prescribed dietary regimens. By allowing the physician to select a meal plan that is specifically tailored to the patient, the patient's chances of following the plan are greatly enhanced. Likewise, the user may select a meal that in turn may increase the chance of success. In addition, the system makes data capture of meals and other information simpler, so that users are more likely to enter information, thereby improving compliance tracking of the program. The system also provides automatic feedback to show how well the user is complying with the prescribed dietary regimen. Physicians or other Health Care Providers (HCPs) as well as users can easily view the results hourly, daily, weekly, monthly, or even yearly to determine how well the user complies with the regimen, and make adjustments to the diet if needed. By making it easier for the user to enter food consumption information, more accurate results of the structured test can be easily achieved.

Fig. 1 shows a block diagram of one example of a meal compliance system 100 configured to perform this technique for simplifying data entry for tracking meal compliance. As can be seen, the meal compliance system 100 includes a portable device 102, a glucose meter 103, a food database 104, and a Health Care Provider (HCP) computer 106. The portable device 102, the food database 104, and the HCP computer 106 communicate with each other via a network 108. The patient or user uses the portable device 102 to retrieve meal information from the food database 104 and to enter information about meal consumption. In one example, the portable device 102 includes a smart phone and/or a cellular phone type device such that the portable device is easily accessible to the user. The portable device 102 is used in conjunction with a glucose meter 103 to collect glucose readings from a patient. In the illustrated embodiment, the glucose reading is downloaded from the glucose meter 103 onto the portable device 102. The food database 104 contains a database and/or other data structure in which nutritional/dietary information about various foods is stored. For example, the food database 104 may list hundreds of restaurants and their calorie, fat, carbohydrate, and fiber information. This information is accessible throughout the system 100 and may be filtered in any number of ways, such as by location. The food database 104 stores information about meal consumption and other patient information collected by the portable device 102. In one example, the food database 104 comprises a Structured Query Language (SQL) type database, such as MICROSOFT ® SQL servers or ORACLE type databases. A physician and/or other health care provider uses the HCP computer 106 to enter information, such as a prescribed meal and health records for a patient, into the food database 104 and retrieve the information to see how well the patient follows the prescribed meal. In one example, the HCP computer 106 comprises a Personal Computer (PC), such as a desktop and/or laptop computer located at a physician's office. To facilitate wide access to the data stored in the food database 104, in one example, the network 108 includes a combination of private and public networks, such as a private wireless network connected to the internet.

As will be explained in more detail below, the food database 104 is configured to supply the portable device 102 with a list of potential menu items based on particular circumstances surrounding the patient. For example, the portable device 102 provides customized menu items from which the user may select based on the patient's location. In fig. 1, reference numeral 110 is associated with a first food source location (such as a grocery store or restaurant), and reference numeral 120 represents a second food source location that is different from the first food source location 110, such as another grocery store or restaurant. The food database 104 stores a list of food items.

Returning to the previous example, when the patient is at the first food source location 110, the portable device 120 filters, sorts (e.g., ranks), and/or highlights menu items via the food database 104 as those menu items that are available at the first food source location 110 (and not at the second food service location 112). Likewise, when the patient is at the second food source location 112, the portable device 120 filters, sorts, and/or highlights menu items to those available at the second location 112.

Fig. 2 shows a block diagram of one example of components of the portable device 102. As shown, the portable device 102 includes: a processor 202 for processing data, a memory 204 for storing data, an input device 206 for inputting data, and an output device 208 for outputting information. The portable device 102 also includes a Location Detection System (LDS) 210, such as a Global Positioning System (GPS) and/or assisted GPS type system, for detecting the location of the portable device 102. The portable device 102 also includes a clock 212, the clock 212 being used to determine the time of day to assist in determining what type of meal (e.g., breakfast, lunch, or dinner) is appropriate at that time. The input device 206 is used to input data and generally operate the portable device 102, and the output device 208 is configured to provide information to a user. In one example, where the portable device 102 is a smart phone, the input device 206 and the output device 208 are combined together into a touch-type display. For communication over the network 108, the portable device 102 includes a communication device 214, the communication device 214 being capable of communicating information wirelessly and/or via a wired type connection. For example, the communication device 214 may include a transceiver found in a cellular telephone.

The overall technique of utilizing the meal compliance system 100 will now be described with reference to the flowchart 300 illustrated in fig. 3. Looking at the flow diagram 300, at a data capture stage 302, a healthcare provider (such as a physician) selects a dietary regimen specifically tailored to a patient. If appropriate, the physician may negotiate with the patient to determine which meal will best suit the lifestyle of the particular patient. The patient may choose the meal himself or, if so desired, in some instances, not need to select a meal. Referring to fig. 1, once the physician and/or patient makes a decision on a meal regimen, the physician enters or otherwise associates a particular meal to the patient in the food database 104 via the HCP computer 106. The physician may select a meal from a predefined list of meals in the food database 104 or may develop a custom meal specifically tailored to the patient. The specific dietary regimen may vary from patient to patient. For example, many meal plans are available (such as Atkins, South Beach, Body for Life), as well as meal plans more specific to people with diabetes and meal plans created for a particular user. The system 100 is designed to identify by location those menu items that are suitable for a prescribed or preset meal.

After the meal for the patient is specified, the user can utilize the portable device 102 to collect meal and other data in the data capture and reporting phase 304. The user can input information (such as meal selection and physiological information) into the portable device 102 via the input device 206. To identify the patient, the portable device 102 may include a unique identifier associated with the patient in the food database 104 and/or the patient may utilize a unique user id and password to log into the food database 104 via, for example, the portable device 102. By identifying a particular patient, via the portable device 102, the food database 104 can provide a customized interface to simplify data entry for the patient, among other things. This simplification of the meal entry process also helps to provide more accurate information about the food being consumed, which can be quite helpful for structured test data analysis. By making data entry seamless, the user is more likely to enter information, thereby improving compliance tracking with the meal plan. For example, as will be explained in more detail below, LDS 210 may help improve menu items provided to a user based on the user's location. The clock 212 may also be used to further refine the menu items available based on the meal that is appropriate at a particular time of day. Additionally, the memory 204 in the portable device 102 and/or the food database 104 may store historical selections to further refine the menu items. In stage 304, the output device 208 of the portable device 102 can provide immediate feedback to enable the patient to monitor how well they are following the meal and to check their health statistics.

To see how well the patient is complying with the prescribed meal and monitoring the patient's health, the physician may view the patient results from the food database 104 via the HCP computer 106 in stage 306. For example, a physician may generate a report to see if a patient exceeds the daily calorie and/or carbohydrate intake prescribed for a meal. If the patient does not properly follow the meal, the physician can take corrective action to remedy the situation, such as by counseling the patient about the meal. Likewise, if the patient does not respond to a prescribed meal, the physician may prescribe a different meal and/or structured test in order to find the source of the problem. Based on how well the patient is following the dietary regimen and other physical conditions (such as blood glucose levels and blood pressure), the physician may further improve the patient's dietary needs and the process may be repeated again as indicated by the dashed arrows in flowchart 300.

The ability of the portable device 102 to customize the interface is further expanded in stage 304, and the portable device 102 utilizes unique techniques that allow it to specifically customize and refine the list of available menu items to reduce the effort required by the user to enter data. Flow diagram 400 in fig. 4 illustrates a technique for simplifying data entry and providing compliance metrics. To illustrate this technique, the portable device 102 in this particular example is a smart phone that accesses the food database 104 over the internet. The food database 104 in this example is a network-hosted server that provides meal data to the portable device 102 and records menu items selected by the patient along with other data entered through the portable device 102. Referring to fig. 1 and 2, in stage 402, the portable device 102 detects its location using the LDS 210. In this example, LDS 210 uses GPS coordinates to detect its location. Based on the detected location, the portable device 102 queries the food database 104 in stage 404, and the food database 104 returns a list of menu items for that particular location. For example, if the first food source location in fig. 1 is a fast food restaurant, the processor 202, via the food database 104, refines the list of available food items based on the location. If the portable device 102 is located at the second food source location 112, the menu of items will be based on the items available at that location. For example, if the user followed the Body for Life meal (40% carbohydrate, 40% protein, 20% fat) and they appeared in a fast food restaurant, the system would specify chicken sandwiches and salad or a bowl of paprika as those items appropriate for specifying the meal. This grading of protein food alternatives enables and administers meals strongly. Meals tend to state what you cannot have rather than what you can have, which is facilitated by the system. In another example, if a user arrives at a restaurant and opens the food database 104, those entries that reflect the restaurant menu entries will be made "default" (e.g., appear at the top of the list). Specifically, if the user walks into McDonald's restaurants, the portable device 102 will present a menu of the particular McDonald restaurants rather than a menu of, say, Hamburg King restaurants.

Based on the time of day from the clock 212, the processor 202 of the portable device 102 can also refine the menu list of available items supplied to the user in stage 406. For example, if it is around lunch time, only the lunch time item will be displayed for that particular location instead of an item from the breakfast menu. The timing of a particular meal can be customized based on the particular circumstances of the user. For example, shift workers may eat their "breakfast" in the afternoon and their "dinner" in the morning. In stage 408, the processor 202 of the portable device 102 ranks the food alternatives based on the meal needs specified by the physician in stage 302. For example, if the physician specifies a low carbohydrate diet, items with lower carbohydrates will be assigned a higher rank so that they will appear higher or first on the list than items with higher carbohydrates (or vice versa). Screenshot 500 in FIG. 5 illustrates one example of ranking items based on location. As shown in this particular example, the physician has specified a low calorie diet and the items as shown in screenshot 500 are ranked by calorie such that lower calorie items ("salads") appear at the top of the list and items with higher calorie values (e.g., "chicken") appear at the end of the list.

In the event that there is no content on the menu that satisfies the prescribed or predetermined meal, the system 100 may use the current location to identify and suggest alternative restaurants in which the meal may be followed. Looking at stage 410 in fig. 4, the food database 104 determines whether there are any food alternatives at that location that meet the needs of a particular meal. If not, the meal compliance system 100 is designed to suggest alternative locations for approaching the user in stage 412. For example, if a pure vegetarian diet is prescribed to a patient and they are located at a steak house, the food database 104 suggests a nearby vegetarian restaurant via the portable identification 102. The screenshot 600 illustrated in fig. 6 shows an example of a screen that would be displayed on the output device 208 of the portable device 102 if the restaurant did not meet the meal need. As can be seen, different food locations are ranked by distance, but in other examples, a list of restaurants or other food locations may be ranked based on other variables, such as those that better meet the user's meal needs. Alternatively or additionally, the ranking suggested in stage 412 may also be derived from friend preferences, friend preferences having similar health issues, friend preferences having the same or similar diet, and/or friend preferences having similar profiles provided on one or more social media websites (such as Facebook, Myspace, Foursquare, Yelp, Urbanspoon @, etc.). For example, a friend's recommended restaurant will be assigned a higher rank or listed in a higher location than a restaurant with no comments or poor comments. Once the alternative location is selected and the user travels to that location, the portable device 102 again goes to stage 402 to repeat the cycle until the food alternative meets all dietary needs in stage 410. For example, if the user is near an ice cream store that does not have any items to meet the meal demand, the portable device 102 may suggest to the user to select a yogurt store located within 300 meters as an alternative. In this example, the system 100, via the food database 104, knows the type of food being viewed and will suggest appropriate alternatives as options rather than inappropriate alternatives (such as a steak house or other higher diet).

To further help refine the list to make it easier for the user to make selections, the portable device 102, via the processor 202, ranks the food alternatives based on previous historical selections in stage 414. Alternatively or additionally, the foods may be ranked based on a previous indication of whether a particular food item is a favorite of the user. Once the alternatives are ranked in stage 414, the portable device 102 provides a ranked list of available food items that meet those particular dietary needs in stage 416 via the output device 208. Returning to the smartphone example, in stage 416, a list of ranked menu items may appear on the screen of the smartphone. Again, screenshot 500 in FIG. 5 shows one example of a list of items ranked for a particular restaurant location (which in this example is restaurant A). Users have the ability to show only their favorite meals, show all meals, and show nearby restaurants or other food locations. The food database may present user-created (or system-created) favorites stored in the system, but presented in a prioritized list (and/or removed from the list) based on their location and based on the time of day (e.g., meals). The system 100 can automatically create favorites for a given time and location of day based on repeated meal input. For example, if a user is at home, their favorite meals that they store at home will be presented by default; however, their favorite meals in mcdonald's would not be presented. If desired, the user may always have access to all of their favorites, but will not be presented directly to them — this would require pressing the "show all favorites" menu selection. Social media may be used for ranking in stage 410. Alternatively or additionally, the ranking of menu items in stage 414 may also be derived from friend preferences, friend preferences having similar health issues, friend preferences having the same or similar diet, and/or friend preferences having similar profiles provided on one or social media websites (such as Facebook ®, Myspace ®, Foursquare @, Yelp @, Urbanspoon @, etc.). For example, a menu item that a friend likes will be assigned a higher rating than a menu item that has no rating or a poor rating. The system 100 also has the ability to track and/or rank meal information based on a particular restaurant chain visited. For example, if a person eats at a first mcdonald's restaurant in one state and later visits a second mcdonald's restaurant in a different state, the selection or preference from the first mcdonald's restaurant is persisted to the second mcdonald's restaurant so that the previous selection affects the ranking of meals in the second mcdonald's restaurant. In addition, storage-specific menu items may also be tracked and/or ranked within a particular restaurant chain.

The portable device 102 also has the ability to input data via the input device 206, if desired. Referring to fig. 4, in stage 418, the user can enter data (such as physiological data) and other information related to their health, mental state, environment, and/or other information used by the physician to monitor the patient. For example, in stage 418, the user may enter their blood glucose reading, blood pressure, pulse, and/or other physiological data. Screenshot 700 in fig. 7 illustrates but one example of an input screen displayed on output device 208 in which a user can enter a blood glucose measurement. In another example, the blood glucose meter communicates the glucose measurement directly to a smartphone, and in yet another example, the portable device 102 is a blood glucose meter that automatically records blood glucose measurements.

The portable device 102 is configured to provide feedback to enable the user to see how they are performing in relation to prescribing a meal, as well as to check their overall health. In stage 420, the portable device 102 and/or the HCP computer 106 can provide compliance metrics on how well the individual is following their dietary regimen. Fig. 8 illustrates a screen shot 800 of one example of a compliance report that may be displayed on the output device 208 of the portable device 102. Fig. 9 shows another display screen 900 which is used to show how well an individual is complying with their particular dietary needs. By making it easier for users to check their compliance with a particular dietary regimen on-the-fly, users are provided with better feedback to ensure that they are properly compliant with their dietary and nutritional regimens.

In one particular use example, a physician enters a particular low carbohydrate diet for a patient into the food database 104 via the HCP computer 106. As mentioned previously, the food database 104 includes a large amount of information about a particular meal and information about which food items will or will not be suitable for a prescribed low carbohydrate meal. The user carries a portable device 102 in the form of a smart phone that includes a GPS subsystem capable of detecting the user's location. Most of the information storage and processing is performed on a remotely hosted food database 104 that is accessed by the smartphone over the internet. The smart phone accesses the food database 104 using a proprietary client program or through a standard web browser, such as one using HTML5 standards or other variants. In this remotely hosted configuration, the smartphone is not constrained by storage and/or processing power limitations. The smartphone continuously or periodically transmits its GPS coordinates to the food database 104. Based on the location from the GPS, the food database can prioritize nutritional information about food served at various nearby locations, such as restaurants, hotels, supermarkets, and/or even at home. This information is transmitted from the food database 104 and displayed as a web page on the smart phone. For example, if a user arrives at a restaurant (such as a fast food restaurant) and opens an application containing meal information on their cell phone, an entry for a menu reflecting a particular location will appear by default.

To help further improve the selection and reduce the consequences that make the selection process easier for the user, the food database 104 also improves the menu list based on the time of day (such as whether it is breakfast, lunch or dinner) and historical meal selections. In this low carbohydrate use example, the user enters a restaurant during breakfast. The food database 104 will display a list of menu items on the smartphone with low carbohydrate breakfast items (such as eggs) displayed at the top of the list, while higher carbohydrate items (such as pancakes and toasts) are displayed near the bottom of the list. Other nutritional information, such as fat, calorie, and carbohydrate content, is displayed alongside the description of the item). Social media reviews of the menu items and/or restaurants may also be displayed. The food database 104 even suggests on the smartphone specific breakfast items suggested by friends with similar meals based on information gleaned from social media network data. By providing specific menu items based on meal needs, users are better able to follow their meal plan. In the absence of available items that meet the user's dietary needs (e.g., the user visits a pancake restaurant), the smartphone may suggest an alternative nearby restaurant with a lower carbohydrate meal option. By making improved meal selections, users can quickly and effortlessly enter specific information about their meals. The accuracy of the entered information is also improved.

Compliance metrics showing how well a user is complying with their daily meal needs may be provided immediately on the smartphone so that the user may take corrective action. The user may for example inform them that they are close to their daily carbohydrate limit and therefore they may decide to eat a smaller amount of a high protein meal instead of a pasta dinner. In this example, the physician also requires the patient to measure and record their blood glucose levels as part of the structured test, both before and two hours after each meal. Following the physician's order, the patient measures their blood glucose with a blood glucose meter, which wirelessly transmits the glucose readings to a smart phone, which in turn automatically transmits the data to a food database. The physician can then immediately monitor the patient's health and take corrective action if necessary. For example, the food database may alert the physician to a hypoglycemic or near hypoglycemic event. The physician may view a web page showing specific information about previous meals, in conjunction with other collected data (such as glucose, activity and energy levels) on the HCP computer 106 in order to locate the potential root cause of hypoglycemia, and where appropriate, the physician may even modify or change prescribed meals remotely, even without requiring the patient to visit an office.

As mentioned previously, the above described techniques and systems may be particularly helpful for a structured test program (such as having ACCU-CHEK 360 View blood glucose analysis System) because the data input is simplified and the data accuracy is improved. One non-limiting example of a structured test protocol that may be used is described in U.S. patent application No. 12/710,430 (which is incorporated herein by reference), but other structured test protocols may also be used. The simpler it is to enter meals and other information, the more likely it is that the subject of the test will properly perform the structured test. Structured self-monitoring blood glucose (SMBG) test regimens are typically performed in order to locate the likely source of the diabetes control problem and determine the appropriate therapeutic response, whether it is changing for diet, exercise and/or medication. In structured testing, physicians prescribe a predefined test regimen in which blood glucose readings are collected in conjunction with one or more other variables in order to determine the likely source of a glucose control problem. While blood glucose levels, exercise, and drug dosages can be easily quantified and tracked by a patient or subject, quantifying information about meals consumed can be quite difficult. For example, diabetic subjects can fairly easily quantify and accurately record their blood glucose levels, how many miles they run (and for how long), and how much insulin they inject, but this can be an extremely difficult proposition when referring to quantifying calories, carbohydrates, fat, and other nutritional information about the meals they consume. At best, most structured tests require the diabetic to identify whether the meal size is small, medium, or large, which provides little useful information. Furthermore, individuals often tend to underestimate the size and/or calorie content of meals. With the above-described techniques and systems, the subject is in a better position for quantifying the consumed meal for structured testing, which in turn provides better data upon which the physician can diagnose and solve specific problems. Physicians are able to analyze numerous factors of the diet, such as calories, carbohydrates, etc., that may be the source of hypoglycemia or hyperglycemia in diabetic subjects.

It should be appreciated that the above-described systems and techniques may be otherwise adapted to many other types of usage scenarios and/or environments. To illustrate some other use case scenarios, a few more examples will now be provided. In one use case example, a user wants to run a structured test of paired tests. In this type of structured testing, the user takes a blood glucose reading, does something, and then takes another blood glucose sample at some future time. The paired test technique shows any relationship or coupling between two blood glucose readings and actions/events. To illustrate this more specifically, consider the case where a user wants to see the effect of consuming their favorite milkshake. The user initiates a structured test of the paired tests and the portable device 102 prompts the user to take a blood glucose reading. Once the milkshake is consumed, the user selects the milkshake using the food database 104. After two hours, the portable device 102 wakes up and prompts the user to take a second blood glucose reading. A single food input (i.e., milkshake input) is associated not only with one blood glucose reading in the database, but also with both blood glucose readings. It is envisioned that more than two blood glucose readings may be associated with an individual food entry in the food database 104 (and vice versa). For example, a single food input in one example may be associated with up to six blood glucose samples.

In another use case scenario, a structured test is performed to determine the insulin to carbohydrate ratio of the user during the morning or breakfast portion of the day. On a given morning of the test, the portable device 102 prompts the user to take a blood glucose reading and then eat a meal of a predetermined size. Via the food database 104 and the portable device 102, the user identifies a typical morning breakfast that they eat at home and then consumes the breakfast. For each hour after eating breakfast, the portable device 102 collects blood glucose readings, and this continues until six measurements are taken. Thereafter, the portable device 102 and/or the food database 104 compares the blood glucose reading at the beginning of the test with the blood glucose reading at the end of the test and uses the difference, along with the meal size and speed from the food database 104, to calculate the insulin to carbohydrate ratio for the particular meal consumed. In this example, the collected data is used to calculate the results of the structured test without selecting a particular meal.

As another example, the user and physician do not select any particular meal to follow, but instead, the physician wishes to simply perform a structured test using the system. When the portable device 102 requires the user to enter meal information for testing, the user may use the food database 104 to enter meals. Alternatively, the user may manually enter information about the meal (e.g., carbohydrates, size, calories, etc.) without using the food database 104. Subsequently, the data from the structured test is analyzed by the physician.

For yet another example of a use case scenario, a user decides that they want to follow South Beach Diet and programs the system accordingly. The system 100 supports user compliance with a Diet in the manner described above, such as by providing menu items suitable for South Beach Diet @, along with a Diet compliance metric. Upon visiting the physician, both the user and the physician decide on different meal plans, and the physician enters a new meal via the HCP computer 106. Thus, the system 100 will no longer support South Beach Diet previously selected for the user; but the system 100 provides support for a newly selected meal.

As should be appreciated, these techniques and systems may be adapted to collect additional information and/or provide additional functionality. For example, a bolus calculator may use food consumption information facilitated by the food database 104. Thus, the bolus calculation can be tailored to a particular individual. For structured testing purposes, as well as for other purposes, the system 100 may be used to collect other information (such as exercise information, stressors, etc.) and align or associate the information with a particular meal. Alternatively or additionally, the location coordinates of the user may be directly associated with the individual glucose readings to determine, among other things, whether the location is likely to indicate a glucose problem. Within the food database 104, a meal rise in blood glucose readings (e.g., a change in blood glucose level between before and 2 hours after a meal) may also be associated with a particular meal consumed. In another example, pre-meal and post-meal blood glucose readings are stored in meal groupings within a food database. Meal groupings can be created based on common traits shared between meals. For example, meals that are eaten at particular times and/or that share common food may be used to form meal groupings. It should be appreciated that other characteristics may be used to form or identify meal groupings. Data from these meal groupings can be statistically processed (e.g., mean, median, minimum, maximum, mode, range, etc.) and saved so that the impact from each meal grouping can be used to identify problems. The system 100 may also be configured to track existing treatments of the user so that if the treatments change, the system 100 may help deploy recommended meal changes accordingly.

The systems and techniques illustrated and described above are but a few examples, and it is contemplated that many other examples are possible. For example, in other embodiments, the system 100 in FIG. 1 may be configured differently. For example, the portable device 102 is described as being a smart phone and/or cellular phone type device, but in other examples, the portable device 102 may take other forms, including but not limited to a portable computer (such as a tablet computer, a laptop computer, a portable digital assistant) and/or a health monitoring system (such as a blood glucose meter, a blood pressure monitoring device, and/or a portable heart monitoring device), to name a few examples. The food database 104 is described as being a Structured Query Language (SQL) type database, such as MICROSOFT SQL servers or ORACLE type databases residing on network hosting server type computers, although it is contemplated that other types of data storage and processing systems may be used. For example, the food database 104 may reside, in whole or in part, on the portable device 102, the HCP computer 106, and/or throughout a distributed network, to name a few alternative examples. When the food database 104 is network capable, a large number of locations may be supported, and the portable device 102 will not be constrained by storage size and processing power limitations. In one example, the HCP computer 106 includes a Personal Computer (PC), such as a desktop computer and/or a laptop computer. However, in other examples, the HCP computer 106 may include a tablet style computer, a smart phone, a cellular phone, a terminal, and other components that allow for electronic data input and/or manipulation.

The various components of system 100 communicate internally and/or throughout network 108 by sending and receiving various signals. Although network 108 is described as including the internet, network 108 may include any form of communication network, such as a telecommunications system, a cellular communication system, the internet, one or more other Wide Area Networks (WANs), a Local Area Network (LAN), a proprietary network, an enterprise network, a cable television network, a Public Switched Telephone Network (PSTN), combinations of these, and/or other types of networks generally known to those of skill in the art. The components of the system 100 may communicate throughout the network 108 in any number of ways, such as in a continuous, periodic, synchronous, and/or asynchronous manner. It is contemplated that network 108 may not be required in other examples. For example, when the food database 104 resides on the portable device 102, the portable device 102 may be programmed directly by a physician and/or through a direct connection (such as via a USB port) with the HCP computer 106.

The first and second food source locations 110, 112 include any location where food can be provided. By way of non-limiting example, the first and second food source locations 110, 112 may include restaurants, pubs, hotels, supermarkets, homes, clubs, and/or fast food restaurants, to name a few examples. In the example shown in fig. 1, two food source locations are illustrated, but it is contemplated that the database may store information for many more food source locations.

In the illustrated embodiment, the portable device 102, glucose meter 103, food database 104, HCP computer 106, and network 108 are shown as separate components. One or more of these components may be combined together into a single unit. For example, instead of food database 104 being separate from portable device 102, the information of food database 104 may be incorporated into portable device 102. As another example, the HCP computer 106 may be merged with the food database 104 to form a single unit. Although the glucose meter 103 is depicted as communicating with other components through the portable device 102, in other examples the glucose meter 103 may communicate or transfer information directly to other components via the network 108. Further, the selected components may not necessarily need to communicate via the network 108. For example, the HCP computer 106 may communicate directly with the food database 104 without a network, and vice versa. Although the portable device 102 is shown as a single system, it should also be appreciated that the portable device 102 may include multiple components in communication with each other. For example, portable device 102 may include a cellular telephone (such as a smartphone) that communicates with blood glucose meter 103 via Bluetooth (Bluetooth @). Likewise, the HCP computer 106 and the food database 104 may be configured from multiple components integrated together.

The portable device 102 may be configured differently than the portable device shown in fig. 2. As noted previously, the processor 202 is used to control the operation of the portable device 102. As should be appreciated, the processor 202, in conjunction with other components of the portable device 102, may perform acts in the methods described, illustrated, and/or claimed herein, in part or in whole. For example, processor 202 may be programmed (e.g., via output device 208) to provide the subject with a list of food items in which to emphasize at least the food available at a particular location. It should also be appreciated that processors in other devices of the system (such as the glucose meter 103, the food database 104, and/or the health care provider computer 106) may perform, in part or in whole, the actions in the methods described, illustrated, and/or claimed herein. Processor 202 may be comprised of one or more components. For a processor 202 in the form of multiple components, one or more components may be remotely located relative to the other components or configured as a single unit. Further, the processor 202 may be embodied in a form having more than one processing unit (such as a multi-processor configuration), and the processor 202 should be understood to refer to such a configuration as well as a single processor based arrangement in general. One or more components of the processor 202 may be of an electronic variety defining digital circuitry, analog circuitry, or both. The processor 202 may be of a programmable variety responsive to software instructions, a hardwired state machine, or a combination of these. The clock 212 is used to time events in the portable device 102. As should be appreciated, the clock 212 may be incorporated into the processor 202 or may be a separate component. Further, the clock 212 may be hardware and/or software based.

Among its many functions, the memory 204, in conjunction with the processor 202, is used to store nutritional and meal information along with user-entered meal selections and health information on a temporary, permanent, or semi-permanent basis. The memory 204 may include one or more types of solid-state memory, magnetic memory, or optical memory, to name a few. By way of non-limiting example, memory 204 may include solid-state electronic Random Access Memory (RAM), Sequential Access Memory (SAM) (such as a first-in-first-out (FIFO) variety or a last-in-first-out (LIFO) variety), programmable read-only memory (PROM), electronically programmable read-only memory (EPROM), or electronically erasable programmable read-only memory (EEPROM); optical disk storage (such as Blu-ray, DVD, or CD-ROM); magnetically encoded hard disks, floppy disks, tape, or cartridge media; or a combination of these memory types. Further, memory 204 may be volatile, non-volatile, or a hybrid combination of volatile and non-volatile varieties. Memory 204 may also include removable types of memory. The removable memory may have the form: a non-volatile electronic storage unit, an optical storage disc (such as blu-ray, DVD or CD ROM); magnetically encoded hard disks, floppy disks, tape, or cartridge media; a USB storage drive; or a combination of these or other removable memory types.

With continued reference to fig. 2, the input device 206 may include any type of input device as will occur to those of skill in the art, such as buttons, microphones, touch screens, keyboards, and the like, to name a few examples. Output device 208 may include output devices of the type as will occur to those of skill in the art, such as a display, a haptic device, a printer, a speaker, and so forth, to name a few. Further, it should be appreciated that the input device 206 and the output device 208 may be combined to form a single unit, such as, for example, a touch-type screen. Although the output device 208 of the portable device 102 is described as providing an improved and/or ranked list of food items, it should be appreciated that other output devices separate from the portable device 102 may provide the list. For example, the portable device 102 may be used to locate the user, but a separate electronic menu at a restaurant displays a list of food items specifically tailored to the subject. LDS 210 may comprise any type of system for location detection that may be hardware and/or software based. For example, LDS 210 may include a Global Positioning System (GPS), an assisted GPS type system, a compass and/or accelerometer, and other components for detecting a location or position of portable device 102. In another example, the food database 104 may locate the portable device 102 directly without receiving location coordinates from the portable device 102. In this example, the food database 104 triangulates the location of the portable device 102 based on the Internet Protocol (IP) addresses of one or more routers having known locations through which the portable device 102 communicates. In another example, the location of the portable device may be determined based on the location of a Wi-Fi hotspot through which the portable device 102 communicates. Combinations of techniques may also be used for location detection. For example, the portable device 102 may be located based on some combination of Wi-Fi router location data, 3G/4G cellular tower location data, and GPS coordinate data. The system 100 also allows users to manually enter their locations, such as when GPS line of sight is not available. The communication device 214 may include any type of device and/or software capable of communicating throughout the network 108. For example, the communication device 214 may include a cellular communication type device, a Wi-Fi type device, and/or an infrared port, to name a few examples.

In the above techniques, the physician and/or patient are described as performing certain actions, but it should be recognized that others may perform these actions partially or completely. For example, a physician assistant, nurse, administrator, dietician, and/or third party may perform the actions described with reference to a physician, and a family member, nurse, assistant, employee, or other individual may assist the patient in entering information into the portable device 102 or elsewhere. It should be recognized that other people may enter and/or prescribe dietary regimens. In one particular example, the physician may mail or send the form via fax to a centralized location where the dietary regimen is entered into the food database 104. The physician and/or patient may also enter a dietary regimen via the portable device 102. As previously mentioned, the patient may also select a dietary regimen. Illustratively, imagine that patients would like to follow South Beach Diet et al. Based on the patient's location, the system 100 highlights the food at a meal-compliant location. Later in this example, if the physician specifies a different meal, the system 100 will override the previous patient selected meal to support the new meal plan specified by the physician. Although a physician, other health care provider (e.g., a dietician), patient, and/or other person may assist in selecting a meal method in stage 302 (fig. 3), it is contemplated that the system 100 and techniques may be used without selecting or prescribing a meal method. Without selecting a meal in stage 302, the user is still able to enter information such as meals consumed and blood glucose readings. However, assuming no meal is specified, the system 100 will not be able to support the reporting of meal compliance metrics, but the system 100 will still be able to support other functions. In other words, the system 100 is able to capture data and provide the data for structured testing purposes even when no meal method is selected.

In terms of providing information such as food, meals, meal compliance, and restaurant information, it should be appreciated that the system 100 at least emphasizes relevant information in order to simplify the user's selection process. As used herein, the term "emphasis" or any variation of that term (e.g., "emphasized") means: the related information is pointed out and/or called for the user's attention so that the user can easily recognize the related information. By way of non-limiting example, the provided information may be emphasized by reducing the amount of information provided (e.g., a limitation on a list), ranking information, filtering information, sorting information, highlighting information, underlining information, increasing volume as information is played, and/or color coding information, to name a few examples. In one example, the list of available restaurants or other food locations is limited based on the user's location, and then the food or meals are ranked based on how well the user follows the user's meal. However, there are other possibilities that help simplify the selection process. Using the example of a hierarchical approach, restaurant names first appear based on location. Then, upon selection of a restaurant, a hierarchical order of menu items or food items is displayed, wherein previously selected items are highlighted. It should also be appreciated that the interface may differ from what is shown in the figures. For the visually impaired and for others, the portable device 102 in one example uses text-to-speech (and speech-to-text) technology to interface with the user, and in other variations, the display is used to interact with the user. As another example, the listing of food items may incorporate two tags, one listing meals and the other listing individual food items. To customize and/or generate information about a particular meal, a user may combine one or more food items under a food item label to create a meal. In addition, the user may manually enter meal information that is not present in the food database 104.

The various stages of the above-described techniques may be performed in a different order than illustrated in the figures and/or described above. For example, in FIG. 4, the menu of food items may be improved based on time (stage 406) after ranking the menu items with respect to historical selections (stage 414). During the data capture and reporting phase 304, the information contained in all or a portion of the food database 104 may reside on the portable device 102. For example, where network coverage of a smartphone is not readily available, the entire food database 104 may reside in the memory 204 of the portable device 102. Conversely, where network communications are readily available, only the required information from the food database 104 is transferred via the network and temporarily stored in the memory 204 of the portable device 102.

While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only the preferred embodiment has been shown and described and that all changes, equivalents, and modifications that come within the spirit of the invention as defined by the following claims are desired to be protected. All publications, patents, and patent applications cited in this specification are herein incorporated by reference as if each individual publication, patent, or patent application were specifically and individually indicated to be incorporated by reference and set forth in its entirety herein.

Disclosed is a method for obtaining information about food consumed by a subject of a blood glucose test, the method comprising: determining a location of a portable device owned by the object; providing the subject with a list of food items in which at least food available at the location is emphasized; receiving a selection from the list indicating food consumed by the subject; and collecting a blood glucose reading from the subject.

In a further development of the method, providing the list of food items to the subject further comprises emphasizing at least the food items in the list based on historical food preferences of the subject.

In a further development of the method, providing the list of food items to the subject further comprises emphasizing at least the food items in the list based on the dietary needs of the subject.

In a further development of the method, providing the list of food items to the subject further comprises emphasizing at least the food items in the list based on the time of day.

In one development, the method further comprises ranking the food items on the list based on the subject's dietary needs.

In one development, the method further comprises providing, via the portable device, a metric showing compliance of the subject with the meal.

In one development, the method further comprises: determining that the location lacks a food item that meets a dietary need of the subject; and providing, via the portable device, a list of alternative locations that satisfy the subject's dietary needs.

In one development, all the recited actions are performed by a portable device.

In one development, the recited acts are performed in whole or in part by a food database located remotely from the portable device.

In one development, collecting the blood glucose reading includes receiving the blood glucose reading from a blood glucose meter.

In one development, the blood glucose meter is integrated into a portable device.

In one development, the method further provides the list of food items to the subject includes displaying the list of food items on a portable device.

In one development, the method further comprises correlating food consumed by the subject to blood glucose readings in a food database.

In one development, consumed food and blood glucose readings are stored with a time stamp.

In one development, the method further comprises: the consumed food is associated with the blood glucose reading when the consumed food and the blood glucose reading occur within the defined time interval.

In one development, the method further comprises triggering a reminder system after a defined period of time after the receiving of the selection.

In one development, the method further comprises providing the results of the blood glucose test to a health care provider computer.

In one development, providing the list of food items to the subject includes emphasizing food available at the location by filtering the list of food items to provide only food available at the location.

In one development, providing the list of food items to the subject includes emphasizing the food available at the location by ordering the list of food items based on proximity to the user.

In one development, the method further comprises: storing the blood glucose reading and the selection of food consumed in a memory; and processing at least the blood glucose reading and the selection of consumed food to identify any pattern of the structured blood glucose test.

In one development, receiving a selection and said collecting a blood glucose reading are performed at different times.

Also disclosed is a method comprising: receiving a dietary regimen using a food database; receiving, with a food database, location data corresponding to a location of a portable device carried by a subject; generating, with a food database, a list of food items in which at least food items available at the location that satisfy the subject's dietary regimen are emphasized; emphasizing food items in the list based on historical food preferences of the subject; and outputting the list to the object after the emphasizing.

In one development, the method further comprises the steps of: at least emphasizing food items in the list based on how suitable the food items are for a particular time of day before the outputting.

In one development, emphasizing food items in the list based on historical food preferences comprises emphasizing food items previously consumed by the subject on the list.

In one development, the method further comprises receiving a blood glucose reading from the subject using a food database.

In one development, dietary regimens are prescribed by physicians.

In one development, dietary regimens are selected by the user.

In one development, the portable device is a cellular telephone.

In one development, the method further comprises receiving information about the meal consumed by the user created by the user selecting more than one item from the list.

In one development, the location is a restaurant, or a residence, or a grocery store.

A system configured to perform a method according to any of the disclosed developments is disclosed.

In one development, a system for obtaining information about food consumed by a subject of a structured blood glucose test comprises: a portable device configured to be owned by the subject, the portable device having a location detection system configured to provide data indicative of a location of the portable device; a food database configured to provide the portable device with a list of food items that at least emphasize food available at the location; wherein the portable device comprises an output device configured to display a list of food items and an input device configured to receive a selection from the list indicative of food consumed by the subject; a blood glucose meter configured to read a blood glucose reading from the subject; and wherein the food database is configured to store blood glucose readings and information about food consumed by the subject.

In one development, the food database is separate from the portable device. In another development, the food database is incorporated into the portable device.

Disclosed is a system for obtaining food consumed by a subject of a blood glucose test, comprising: a portable device configured to be owned by the subject; a location detection system configured to determine a location of a portable device; the portable device includes: a processor configured to process blood glucose readings from the subject; an output device configured to provide a list of food items from the processor that emphasizes at least food available at the location; and an input device configured to receive a selection from the list indicating food consumed by the subject.

In one development, the system further comprises a memory storing a selection from the list indicating the food consumed by the subject.

In one development, the memory is configured to store the selection together with a blood glucose reading.

In one development, the system further comprises a food database configured to supply the list of food items to the processor.

In one development, the food database is separate from the portable device.

In one development, the position detection system is incorporated into the portable device.

In one development, the position detection system is separate from the portable device.

In one development, the system further comprises a glucose meter configured to measure a blood glucose reading from the subject.

In one development, the blood glucose meter is incorporated into the portable device.

In one development, the blood glucose meter is separate from the portable device.

Claims (23)

1. A method for obtaining information about food consumed by a subject of a blood glucose test, the method comprising:

determining a location of a portable device owned by the object;

providing the subject with a list of food items in which at least food available at the location is emphasized;

receiving a selection from the list indicating food consumed by the subject; and

collecting a blood glucose reading from the subject.

2. The method of claim 1, wherein the providing the subject with the list of food items further comprises at least emphasizing food items in the list based on historical food preferences of the subject.

3. The method of claim 1, wherein the providing the list of food items to the subject at least further comprises emphasizing food items in the list based on dietary needs of the subject.

4. The method of claim 1, wherein the providing the list of food items to the subject at least further comprises emphasizing food items in the list based on a time of day.

5. The method of claim 1, further comprising ranking food items on the list based on the subject's dietary needs.

6. The method of claim 1, further comprising providing, via a portable device, a metric showing compliance of the subject with a meal.

7. The method of claim 1, further comprising:

determining that the location lacks a food item that meets a dietary need of the subject; and

providing, via the portable device, a list of alternative locations that satisfy the subject's dietary needs.

8. The method of claim 1, wherein all recited acts are performed by a portable device.

9. The method of claim 1, wherein the recited acts are performed in whole or in part by a food database located remotely from the portable device.

10. The method of claim 1, wherein the collecting a blood glucose reading comprises receiving a blood glucose reading from a blood glucose meter.

11. The method of claim 10, wherein the blood glucose meter is integrated into a portable device.

12. The method of claim 1, wherein the providing the list of food items to the subject comprises displaying the list of food items on a portable device.

13. The method of claim 1, further comprising correlating food consumed by the subject to blood glucose readings in a food database.

14. The method of claim 1, wherein the consumed food and blood glucose readings are stored with a time stamp.

15. The method of claim 1, further comprising: the consumed food is associated with the blood glucose reading when the consumed food and the blood glucose reading occur within the defined time interval.

16. The method of claim 1, further comprising triggering a reminder system after a defined period of time after the receiving a selection.

17. The method of claim 1, further comprising providing the results of the blood glucose test to a health care provider computer.

18. The method of claim 1, wherein the providing the list of food items to the subject comprises emphasizing food available at the location by filtering the list of food items to provide only food available at the location.

19. The method of claim 1, wherein the providing the list of food items to the subject comprises emphasizing food available at the location by ordering the list of food items based on proximity to a user.

20. The method of claim 1, further comprising:

storing the blood glucose reading and the selection of food consumed in a memory; and

at least the blood glucose reading and the selection of consumed food are processed to identify any pattern of the structured blood glucose test.

21. The method of claim 1, wherein the receiving a selection and the collecting a blood glucose reading are performed at different times.

22. A system configured to perform the method of any preceding claim.

23. The system of claim 22, comprising:

a portable device configured to be owned by an object, the portable device having a location detection system configured to provide data indicative of a location of the portable device;

a food database configured to provide the portable device with a list of food items that at least emphasize food available at the location;

wherein the portable device comprises:

an output device configured to display a list of food items; and

an input device configured to receive a selection from the list indicating food consumed by the subject;

a blood glucose meter configured to read a blood glucose reading from the subject; and

wherein the food database is configured to store blood glucose readings and information about food consumed by the subject.