HK1194508B - Location enabled food database - Google Patents

Description

Location-enabled food database

Background Art

For those with special dietary needs (such as diabetics), there is a strong need to monitor and control their dietary and nutritional needs. As a practical matter, while understanding the need to closely control their dietary needs, there are many obstacles that diabetics experience when trying to control their food intake and accompanying blood sugar levels. If not properly addressed, multiple serious health problems may occur. Therefore, there is a need for improvement in this area.

Summary of the Invention

It has been found that when physicians or other health care providers (HCPs) provide general health recommendations (such as instructions to lose weight, exercise more, etc.), they are not sufficient to successfully achieve desired results. However, when physicians provide specific dietary and/or exercise goals, the success rate of achieving the goals improves dramatically. For example, if the physician simply says "exercise more," the results are dramatically worse than if the patient is prescribed to run 5 miles per week. Similarly, patients are more likely to follow a dietary regimen that provides precise dietary guidelines, such as one with specific calorie, carbohydrate, and nutrient goals, than a general recommendation to "eat less."

Even when specific health guidelines are provided, when determining whether the patient actually complies with the recommendation, the patient also will experience significant obstacles. The patient may become frustrated because of the process of completing and collecting the large amount of data required for monitoring compliance. In other words, the more steps consumed, the more unlikely someone will input accurate data, if someone really wants to input data. For example, there is a large amount of nutritional information available on the Internet, but finding the dietary information that is applicable to a specific meal can also be daunting in the best case scenario. The patient must usually complete a huge amount of information to receive the nutritional information they want. This burden is coupled with the possibility that they will follow the prescribed plan when time is tight. In addition, even when the patient finds correct information, they may also learn that the specific meal they intend to eat is not suitable for prescribed meal, and thus, they are faced with the dilemma of ignoring the dietary plan by eating meal in any way or following this plan but coping with the difficult task of finding the alternative meal that satisfies the dietary goal.

The inventors of the present invention have developed a unique system and method for simplifying the process of inputting meals and other information to determine compliance with a prescribed diet. 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.), dietary needs, and/or historical meal preferences (e.g., favorite meals). This is convenient for inputting nutritional information because only the patient is presented with information relevant to their location and their dietary needs and preferences. For example, the system has the ability to classify alternatives based not only on location but also on the time of day to customize menu lists and based on dietary needs and historical selections. By classifying menus and improving menus and providing a short list customized to a specific user, information can be accurately and easily input without the user having to rummage through multiple alternatives that may be frustrating. If the available menu items do not meet specific dietary needs, the system can also suggest neighboring institutions (such as other restaurants) with meals that meet dietary needs.

The system is also configured to provide a compliance metric that shows how well the user is following the diet based on the food identified as consumed. By doing so, the user can see their compliance trends over time and, if necessary, take corrective action to fix any issues. Furthermore, healthcare providers can assess how well the user is following the dietary regulations. Physicians can also view physiological data (such as blood sugar levels, blood pressure, etc.) to monitor the patient's health. If necessary, the physician can modify the patient's specific dietary plan to improve results.

In addition, the system integrates a food database with a structured test regimen. This combination of a meal or food database with a structured test is helpful for tests that rely on meal intake (such as the ACCU-CHEK® 360 review assessment and/or insulin and carbohydrate factor optimization). These structured tests rely on an accurate understanding of carbohydrate intake in order to effectively present reports for treatment optimization purposes. For example, if a patient or subject undergoes an ACCU-CHEK® 360 review assessment and prepares to eat the same morning cereal they eat every day at home, the system will show a favorite for that breakfast meal at the top of the list. After the subject selects the favorite, the information will be provided to the structured test for inclusion in the data set. This helps dramatically enhance the structured test protocol by making it easier to enter more accurate dietary 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.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows a diagrammatic view of a dietary compliance system according to one embodiment.

FIG. 2 is a block diagram of a portable device used in the system of FIG. 1 .

3 is a flow diagram of the overall technique for prescribing a specific meal, capturing data, and reporting compliance.

4 is a flow chart illustrating a technique for selecting a food item and providing a compliance metric.

FIG5 depicts a menu selection screen for a particular food location.

FIG. 6 illustrates a warning screen when a particular food location does not meet dietary requirements.

FIG. 7 shows a data input screen for inputting health data.

FIG8 shows a first compliance reporting screen.

FIG9 shows a second compliance reporting screen.

DETAILED DESCRIPTION

In order to enhance the understanding of the principles of the present invention, reference will now be made to the embodiments illustrated in the accompanying drawings, and specific language will be used to describe the embodiments. However, it will be understood that this is not intended to limit the scope of the present invention. As would be generally expected by those skilled in the art, any changes and further modifications in the described embodiments and any further applications of the principles of the present invention as described herein are contemplated. 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 not related to the present invention may not be shown for the sake of clarity.

For the convenience of the reader, it should be noted initially that the figure in which an element is first introduced is generally indicated by the leftmost digit(s) in the corresponding reference numerals. For example, components identified with one-hundred serial reference numerals (e.g., 100, 101, 102, 103, etc.) will generally be discussed first with reference to FIG1, and components with two-hundred serial reference numerals (e.g., 200, 201, 202, 203, etc.) will generally be discussed first with reference to FIG2.

The dietary compliance system and method described and illustrated herein generally makes it easier for users to adhere to their prescribed dietary regimen. By allowing physicians to select a meal plan specifically tailored to their patients, the chances of the patient following the plan are greatly enhanced. Similarly, users can select meals that may increase their chances of success. In addition, the system simplifies data capture of meals and other information, making it more likely that users will enter information, thereby improving adherence tracking for the plan. The system also provides automatic feedback to show how well the user is adhering to the prescribed dietary regimen. Physicians or other healthcare providers (HCPs) and users can easily review results hourly, daily, weekly, monthly, or even yearly to determine how well the user is adhering to the regimen and make dietary adjustments if necessary. By making it easier for users to enter food consumption information, more accurate results from structured tests can be easily achieved.

FIG1 shows a block diagram of an example of a dietary compliance system 100 configured to implement the technology for simplifying data entry for tracking dietary compliance. As can be seen, dietary compliance system 100 includes a portable device 102, a glucose meter 103, a food database 104, and a healthcare provider (HCP) computer 106. Portable device 102, food database 104, and HCP computer 106 communicate with each other via a network 108. A patient or user uses portable device 102 to retrieve dietary information from food database 104 and input information about meal consumption. In one example, portable device 102 comprises a smartphone and/or cell phone-type device so that the portable device is easily accessible to the user. Portable device 102 is used in conjunction with glucose meter 103 to collect glucose readings from the patient. In the illustrated embodiment, glucose readings are downloaded from glucose meter 103 to portable device 102. Food database 104 comprises a database and/or other data structure storing nutritional/dietary information about various foods. For example, the food database 104 may list hundreds of restaurants along with their calorie, fat, carbohydrate, and fiber information. This information is accessible throughout the system 100 and can be filtered in any number of ways, such as by location. The food database 104 stores information about meal consumption, as well as other patient information collected by the portable device 102. In one example, the food database 104 comprises a Structured Query Language (SQL) database, such as a MICROSOFT® SQL Server or ORACLE® database. Physicians and/or other healthcare providers use the HCP computer 106 to input information (such as a patient's prescribed diet and health records) into the food database 104 and retrieve information to see how well the patient is following the prescribed diet. In one example, the HCP computer 106 comprises a personal computer (PC), such as a desktop and/or laptop computer located in the physician's office. To facilitate broad access to the data stored in the food database 104, the network 108, in one example, comprises a combination of private and public networks, such as a dedicated wireless network connected to the Internet.

As will be explained in greater detail below, the food database 104 is configured to supply the portable device 102 with a list of potential menu items based on the particular circumstances surrounding the patient. For example, the portable device 102 provides customized menu items from which the user can select based on the patient's location. In FIG1 , 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 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 to those available at the first food source location 110 (and not at the second food service location 112) via the food database 104. Similarly, 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.

FIG2 illustrates a block diagram of one example of components of a 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 an assisted-GPS system, for detecting the location of the portable device 102. The portable device 102 also includes a clock 212 for determining 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 the user. In one example where the portable device 102 is a smartphone, the input device 206 and the output device 208 are combined into a touch-sensitive display. To communicate over the network 108, the portable device 102 includes a communication device 214 that is capable of transmitting 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 for utilizing the dietary adherence system 100 will now be described with reference to the flowchart 300 illustrated in FIG3 . Referring to flowchart 300 , at 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 consult with the patient to determine which diet will best suit the patient's lifestyle. The patient may select the diet themselves, or in some instances, no diet selection is required if so desired. Referring to FIG1 , once the physician and/or patient have decided on a dietary regimen, the physician enters or otherwise associates the specific diet with the patient in the food database 104 via the HCP computer 106 . The physician may select a diet from a list of predefined diets in the food database 104 or may develop a custom diet specifically tailored to the patient. The specific dietary regimen may vary between patients. For example, many meal plans are available (such as Atkins, South Beach, and Body for Life), as well as more specialized meal plans for people with diabetes and meal plans created for specific users. The system 100 is designed to identify, by location, those menu items that are appropriate for a prescribed or preset meal.

After specifying a meal for the patient, the user can utilize the portable device 102 to collect meal and other data during the data capture and reporting phase 304. The user can enter information (such as meal selections and physiological information) into the portable device 102 via the input device 206. To identify the patient, the portable device 102 can include a unique identifier associated with the patient in the food database 104, and/or the patient can utilize a unique user ID and password to log into the food database 104 via, for example, the portable device 102. By identifying a specific patient, the food database 104 can provide a customized interface via the portable device 102 to, among other things, simplify data entry for the patient. This simplified meal entry process also helps provide more accurate information about the foods consumed, which can be significantly helpful for structured test data analysis. By making data entry seamless, users are more likely to enter information, thereby improving adherence to the meal plan. For example, as explained in more detail below, the LDS 210 can help refine the menu items offered to the user based on the user's location. The clock 212 can also be used to further refine the available menu items based on meals that are suitable at specific times of the day. In addition, the memory 204 and/or food database 104 in the portable device 102 can 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 so that the patient can monitor how well they are following the diet and check their health statistics.

In order to see how well the patient is following the prescribed diet and to monitor the patient's health, in stage 306, the physician can view the patient's results from the food database 104 via the HCP computer 106. For example, the physician can generate a report to see if the patient exceeds the daily calorie and/or carbohydrate intake prescribed for the diet. If the patient is not following the diet properly, the physician can take corrective action to remedy the situation, such as by advising the patient about the diet. Similarly, if the patient is not responding to the prescribed diet, the physician can prescribe different diets and/or structured tests to get to the root of the problem. Based on how well the patient is following the dietary regimen and other physical conditions (such as blood sugar levels and blood pressure), the physician can further improve the patient's dietary needs, and the process can be repeated again, as indicated by the dotted arrows in the flowchart 300.

Further extending the portable device 102's ability to customize its interface, stage 304 utilizes unique technology that allows it to specifically customize and refine the list of available menu items, thereby reducing the effort required for the user to enter data. The flowchart 400 in FIG. 4 illustrates a technique for simplifying data entry and providing a measure of compliance. To illustrate this technique, the portable device 102 in this particular example is a smartphone accessing a food database 104 via the Internet. The food database 104 in this example is a web-hosted server that provides dietary data to the portable device 102 and records the menu items selected by the patient along with other data entered through the portable device 102. Referring to FIG. 1 and FIG. 2 , in stage 402, the portable device 102 utilizes the LDS 210 to detect its location. In this example, the LDS 210 uses GPS coordinates to detect its location. Based on the detected location, in stage 404, the portable device 102 queries the food database 104, and the food database 104 returns a list of menu items for that specific location. For example, if the first food source location in FIG. 1 is a fast food restaurant, processor 202, via food database 104, refines the list of available food items based on that location. If portable device 102 is located at second food source location 112, the menu of items will be based on the items available at that location. For example, if a user follows the Body for Life diet (40% carbohydrates, 40% protein, 20% fat) and appears at a fast food restaurant, the system will specify a chicken sandwich and salad or a bowl of chili as items suitable for the prescribed diet. This hierarchical organization of protein food options strongly enables and enforces diets. Diets tend to emphasize what you can't have, rather than what you can have, which is something the system promotes. In another example, if a user arrives at a restaurant and opens food database 104, items reflecting the restaurant's menu will be made "default" (e.g., appearing at the top of the list). Specifically, if a user walks into a McDonald's® restaurant, portable device 102 will present the menu for that specific McDonald's restaurant, rather than, for example, the menu for a Burger King® restaurant.

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 offered to the user in stage 406. For example, if it is around lunchtime, only lunchtime items will be displayed for that particular location, rather than items from the breakfast menu. The timing of specific meals can be customized based on the user's specific circumstances. For example, shift workers may eat their "breakfast" in the afternoon and their "dinner" in the early morning. In stage 408, the processor 202 of the portable device 102 ranks the food options based on the dietary requirements 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 ranking so that they will appear higher or first on the list compared to items with higher carbohydrates (or vice versa). The screenshot 500 in Figure 5 shows an example of ranking items based on location. As shown in this particular example, the physician has prescribed a low-calorie diet and has ranked the items shown in screenshot 500 by calories so that lower-calorie items ("salad") appear at the top of the list, while items with higher calorie values (e.g., "chicken") appear at the end of the list.

In the event that there is no food on the menu that satisfies a prescribed or scheduled meal, the system 100 can use the current location to identify and suggest alternative restaurants where the meal can be followed. Referring to stage 410 in FIG. 4 , the food database 104 determines whether there are any food alternatives at the location that meet the specific dietary requirements. If not, the dietary compliance system 100 is designed to suggest alternative locations close to the user in stage 412. For example, if a patient is prescribed a vegan diet and they are at a steakhouse, 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 a restaurant does not meet the dietary requirements. As can be seen, the different food locations are ranked by distance, but in other examples, the list of restaurants or other food locations can be ranked based on other variables (such as those that better meet the user's dietary requirements). Alternatively or additionally, the grading suggested in stage 412 can also be derived from friend preferences, friend preferences with similar health problems, friend preferences with the same or similar meals and/or friend preferences with similar profiles provided on one or more social media websites (such as on Facebook®, Myspace®, Foursquare®, Yelp®, Urbanspoon®, etc.). For example, compared with restaurants without comments or with bad comments, restaurants recommended by friends will be assigned higher grades or listed in higher positions. Once an alternative location is selected and the user travels to the location, portable device 102 will again forward to stage 402 to repeat the cycle until the food alternatives meet all dietary requirements in stage 410. For example, if the user is near an ice cream shop that does not have any items that meet the dietary requirements, portable device 102 can suggest that the user select a yogurt shop within 300 meters as an alternative. In this example, system 100 understands the type of food being viewed via food database 104 and will suggest appropriate alternatives rather than inappropriate alternatives (such as steakhouses or other higher diets) as options.

To further help improve the list so that the user can make a choice more easily, the portable device 102, via the processor 202, selects the food alternatives to be graded in stage 414 based on previous history. Alternatively or additionally, the food can be graded based on the previous indication of whether a particular food item is a favorite of the user. Once the alternatives are graded in stage 414, the portable device 102 provides a graded list of available food items that meet those specific dietary needs in stage 416 via the output device 208. Returning to the smartphone example, in stage 416, a list of graded menu items can appear on the smartphone screen. Once again, the screenshot 500 in FIG5 illustrates an example of a list of graded items for a specific restaurant location (in this example, 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 can present user-created (or system-created) favorites stored in the system, but they are presented in a prioritized list (and/or removed from the list) based on their location and time of day (e.g., meal). The system 100 can automatically create favorites for a given time of day and location based on repeated meal input. For example, if a user is at home, their favorite meals stored at home will be presented by default; however, their favorite meals at McDonald's will not be presented. If desired, the user can always access all of their favorites, but they will not be directly presented to them—this would require pressing the "Show All Favorites" menu option. Social media can be used for ranking in stage 410. Alternatively or additionally, the ranking of menu items in stage 414 can also be based on friend preferences, friends with similar health issues, friends who have the same or similar meals, and/or friends with similar profiles provided on one or more social media websites (such as Facebook®, Myspace®, Foursquare®, Yelp®, Urbanspoon®, etc.). For example, menu items that friends like will be assigned a higher rating than menu items that have no rating or a poor rating. System 100 also has the ability to track and/or rank meal information based on the specific 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 selections or preferences from the first McDonald's restaurant are carried over to the second McDonald's restaurant so that the previous selections affect the ranking of the meal at the second McDonald's restaurant. In addition, within a specific restaurant chain, store-specific menu items can also be tracked and/or ranked.

If desired, the portable device 102 also has the ability to input data via the input device 206. Referring to FIG4, in stage 418, the user can input 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 can input their blood glucose reading, blood pressure, pulse, and/or other physiological data. The screenshot 700 in FIG7 shows only one example of an input screen displayed on the output device 208 in which the user can input a blood glucose measurement. In another example, the blood glucose meter transmits 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 so that the user can see how they are performing with respect to the prescribed diet, as well as check their overall health. In stage 420, the portable device 102 and/or the HCP computer 106 can provide a compliance metric regarding how well the individual is adhering to their dietary regimen. FIG8 shows a screenshot 800 of an example of a compliance report that can be displayed on the output device 208 of the portable device 102. FIG9 shows another display screen 900 that is used to show how well an individual is adhering to their specific dietary requirements. By making it easier for users to instantly check their compliance with a specific dietary regimen, users are provided with better feedback to ensure that they are properly adhering to their dietary and nutritional regimen.

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

To further refine the selection process and reduce the number of consequences for the user, the food database 104 also refines menu listings based on the time of day (such as whether it's breakfast, lunch, or dinner) and past meal selections. In this low-carb use case, the user enters a restaurant during breakfast. The food database 104 will display a list of menu items on the smartphone with low-carb breakfast items (such as eggs) at the top of the list, while higher-carb items (such as pancakes and toast) are displayed near the bottom. Other nutritional information, such as fat, calorie, and carbohydrate content, is displayed alongside the item descriptions. Social media reviews of the menu items and/or restaurants may also be displayed. The food database 104 even suggests specific breakfast items on the smartphone, recommended by friends who have similar meals, based on information gathered from social media networks. By providing specific menu items based on dietary needs, users can better adhere to their meal plans. If no available items meet the user's dietary needs (for example, if the user visits a pancake restaurant), the smartphone can suggest alternative nearby restaurants with lower-carb meal options. By making improved meal selections, users are able to quickly and effortlessly enter specific information about their meals. The accuracy of the information entered is also improved.

A compliance metric showing how well the user is adhering to their daily dietary requirements can be instantly provided on the smartphone, allowing the user to take corrective action. For example, the user can be notified that they are approaching their daily carbohydrate limit and, therefore, may decide to eat a smaller, high-protein meal instead of a pasta dinner. In this example, the physician also requires the patient to measure and record their blood sugar levels before and two hours after each meal as part of a structured test. Following the physician's instructions, the patient measures their blood sugar using a glucometer, which wirelessly transmits the glucose readings to the smartphone, which in turn automatically transmits the data to the food database. The physician can then monitor the patient's health in real time and take corrective action if necessary. For example, the food database can alert the physician to hypoglycemia or near-hypoglycemic events. The physician can view a webpage on the HCP computer 106 that displays specific information about previous meals, along with other collected data (such as glucose, activity, and energy levels), to identify potential sources of hypoglycemia. If appropriate, the physician can even remotely modify or change the prescribed diet, even without requiring the patient to visit the office.

As previously mentioned, the above-described techniques and systems can be particularly helpful for structured testing programs (such as those with the ACCU-CHEK® 360 View Blood Glucose Analysis System) because data entry is simplified and data accuracy is improved. A non-limiting example of a usable structured testing protocol is described in U.S. Patent Application No. 12/710,430 (incorporated herein by reference), but other structured testing protocols may also be used. The simpler it is to enter meal and other information, the more likely the test subject will appropriately perform the structured test. Structured self-monitoring blood glucose (SMBG) testing regimens are often administered to locate possible sources of diabetes control problems and determine appropriate treatment responses, regardless of whether they involve changes in diet, exercise, and/or medication. In structured testing, a physician prescribes a predefined testing regimen in which blood glucose readings are collected in conjunction with one or more other variables to determine possible sources of glucose control problems. While blood glucose levels, exercise, and medication dosages can be easily quantified and tracked by a patient or subject, quantifying information about consumed meals can be quite difficult. For example, diabetic subjects can quite easily quantify and accurately record their blood sugar levels, how many miles they ran (and how long they lasted), and how much insulin they injected, but when it comes to quantifying the calories, carbohydrates, fats, and other nutritional information about the meals they consumed, this can be an extremely difficult proposition. At best, most structured tests require diabetic patients to identify whether the meal size is small, medium, or large, which provides very little useful information. In addition, individuals typically tend to underestimate the size and/or calorie content of a meal. Utilizing the above-mentioned techniques and systems, subjects are in a better position to quantify the meals consumed for structured tests, which in turn provides physicians with better data based on which they can diagnose and solve specific problems. Physicians can analyze numerous factors of the meal that may be the root cause of hypoglycemia or hyperglycemia in diabetic subjects, such as calories, carbohydrates, etc.

It should be appreciated that the above-described systems and techniques can be adapted in other ways for many other types of use case scenarios and/or environments. To illustrate some of these other use case scenarios, a few more examples will now be provided. In one example use case, a user wants to run a structured test called a paired test. In this type of structured test, the user takes a blood glucose reading, does something, and then takes another blood glucose sample at some future time. This paired test technique illustrates any relationship or coupling between two blood glucose readings and actions/events. To illustrate this more specifically, consider a scenario where a user wants to see the impact of consuming their favorite milkshake. The user initiates the structured test of the paired test, 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. Two hours later, the portable device 102 wakes up and prompts the user to take a second blood glucose reading. A single food entry (i.e., the milkshake entry) is associated not only with one blood glucose reading in the database, but also with two blood glucose readings. It is conceivable that more than two blood glucose readings can be associated with individual food entries 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 in the morning or during the breakfast portion of the day. On a given morning of the test, the portable device 102 prompts the user to obtain a blood glucose reading and then eat a meal of predetermined size. Via the food database 104 and the portable device 102, the user identifies the typical morning breakfast they eat at home and consumes breakfast subsequently. For each hour after eating breakfast, the portable device 102 collects blood glucose readings, and this continues until six measurements are obtained. After this, the portable device 102 and/or the food database 104 compare the blood glucose reading at the beginning of the test with the blood glucose reading at the end of the test, and utilize this difference and the meal size and speed from the food database 104 to calculate the insulin to carbohydrate ratio of the specific meal consumed. In this example, the collected data are used to calculate the result of the structured test without selecting a specific meal.

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

For another example of a use case scenario, a user decides they want to follow the South Beach Diet® and programs the system accordingly. The system 100 supports the user in following the diet in the manner described above, such as by providing menu items suitable for the South Beach Diet® and a dietary compliance metric. During a visit to a physician, both the user and the physician decide on a different meal plan, and the physician enters the new meal via the HCP computer 106. As a result, the system 100 will no longer support the South Beach Diet® previously selected for the user; instead, the system 100 provides support for the newly selected meal.

As will be appreciated, these techniques and systems can be adapted to collect additional information and/or provide additional functionality. For example, a bolus calculator can use food consumption information facilitated by the food database 104. Thus, bolus calculations can be customized for specific individuals. For structured testing purposes and for other purposes, the system 100 can be used to collect other information (such as exercise information, stressors, etc.) and align or associate this information with specific meals. Alternatively or additionally, a user's location coordinates can be directly associated with individual glucose readings to, among other things, determine whether the location may indicate a glucose problem. Within the food database 104, meal spikes in blood glucose readings (e.g., the change in blood glucose levels between before and two hours after a meal) can also be associated with the specific meal consumed. In another example, pre-meal and post-meal blood glucose readings are stored in meal groups within the food database. Meal groups can be created based on common characteristics shared between meals. For example, meals eaten at a specific time and/or sharing common foods can be used to form meal groups. It will be appreciated that other characteristics can be used to form or identify meal groups. The data from these meal groupings can be statistically processed (e.g., mean, median, minimum, maximum, mode, range, etc.) and stored so that the impact from each meal grouping can be used to identify problems. The system 100 can also be configured to track the user's current treatment so that if the treatment changes, the system 100 can help develop recommended dietary changes accordingly.

The systems and techniques illustrated and described above are just a few examples, and many other examples are contemplated. For example, in other embodiments, system 100 in FIG. 1 may be configured differently. For example, portable device 102 is described as a smartphone and/or cell phone-type device, but in other examples, portable device 102 may take other forms, including but not limited to a portable computer (such as a tablet, laptop, portable digital assistant) and/or a health monitoring system (such as a blood glucose meter, a blood pressure monitoring device, and/or a portable cardiac monitoring device), to name a few. Food database 104 is described as a Structured Query Language (SQL)-type database, such as a MICROSOFT® SQL Server or ORACLE®-type database residing on a network-hosted server-type computer, but it is contemplated that other types of data storage and processing systems may be used. For example, food database 104 may reside in whole or in part on portable device 102, HCP computer 106, and/or distributed across a distributed network, to name a few alternatives. When food database 104 is network-enabled, a large number of locations can be supported, and portable device 102 is not constrained by storage size and processing power limitations. In one example, the HCP computer 106 comprises a personal computer (PC), such as a desktop computer and/or a laptop computer. However, in other examples, the HCP computer 106 may comprise a tablet computer, a smartphone, a cellular phone, a terminal, or other components that allow electronic data entry and/or manipulation.

The various components of the system 100 communicate internally and/or across a network 108 by sending and receiving various signals. Although the network 108 is described as comprising the Internet, the 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), local area networks (LANs), a proprietary network, an institutional network, a cable television network, a public switched telephone network (PSTN), combinations of these, and/or other types of networks generally known to those skilled in the art. The components of the system 100 may communicate across the network 108 in any number of ways, such as continuously, periodically, synchronously, and/or asynchronously. It is contemplated that in other examples, the network 108 may not be required. For example, when the food database 104 resides on the portable device 102, the portable device 102 may be programmed directly by the physician and/or through a direct connection to the HCP computer 106 (such as via a USB port).

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 a restaurant, a tavern, a hotel, a supermarket, a residence, a club, and/or a fast food restaurant, to name a few. In the example shown in FIG1 , 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, the glucose meter 103, the food database 104, the HCP computer 106, and the network 108 are shown as separate components. One or more of these components can be combined together into a single unit. For example, instead of separating the food database 104 from the portable device 102, the information in the food database 104 can be incorporated into the portable device 102. As another example, the HCP computer 106 can be incorporated with the food database 104 to form a single unit. Although the glucose meter 103 is depicted as communicating with other components via the portable device 102, in other examples the glucose meter 103 can directly transmit or transfer information to other components via the network 108. In addition, the selected components may not necessarily need to communicate via the network 108. For example, the HCP computer 106 can 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 can include multiple components that communicate with each other. For example, the portable device 102 may include a cellular phone (such as a smartphone) that communicates via Bluetooth™ with the blood glucose meter 103. Likewise, the HCP computer 106 and the food database 104 may be configured from multiple components that are integrated together.

Portable device 102 can be configured differently than the portable device shown in FIG. 2 . As previously noted, processor 202 is used to control the operation of portable device 102 . As will be appreciated, processor 202, in conjunction with other components of portable device 102 , can partially or fully perform the actions of the methods described, illustrated, and/or claimed herein. For example, processor 202 can be programmed to provide a list of food items to a subject (e.g., via output device 208 ) that at least emphasizes foods available at a particular location. It will also be appreciated that processors in other devices of the system (such as glucose meter 103 , food database 104 , and/or healthcare provider computer 106 ) can partially or fully perform the actions of the methods described, illustrated, and/or claimed herein. Processor 202 can be comprised of one or more components. For a multi-component processor 202 , one or more components can be remotely located relative to the other components or configured as a single unit. Furthermore, processor 202 can be embodied in a configuration having more than one processing unit (e.g., a multi-processor configuration), and processor 202 should be understood to generally refer to such configurations as well as arrangements based on a single processor. One or more components of the processor 202 may be of an electronic type that defines digital circuits, analog circuits, or both. The processor 202 may be of a programmable type that responds 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 will be appreciated, the clock 212 may be incorporated into the processor 202 or may be a separate component. Furthermore, the clock 212 may be hardware and/or software based.

Among its many functions, memory 204, in conjunction with processor 202, is used to store nutritional and dietary information, along with user-entered meal selections and health information, on a temporary, permanent, or semi-permanent basis. 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) or last-in, first-out (LIFO) type), programmable read-only memory (PROM), electronic programmable read-only memory (EPROM), or electronic erasable programmable read-only memory (EEPROM); optical disk memory (such as Blu-ray, DVD, or CD-ROM); magnetically encoded hard disk, floppy disk, tape, or cartridge media; or a combination of these memory types. Furthermore, memory 204 may be volatile, non-volatile, or a combination of volatile and non-volatile types. Memory 204 may also include removable memory. The removable memory may be in the form of a non-volatile electronic storage unit, an optical storage disc (such as Blu-ray, DVD, or CD ROM); a magnetically encoded hard disk, floppy disk, tape or cartridge media; a USB memory drive; or a combination of these or other removable memory types.

Continuing with reference to FIG. 2 , the input device 206 can include any type of input device as would be appreciated by one skilled in the art, such as buttons, microphones, touch screens, keyboards, and the like, to name a few examples. The output device 208 can include any type of output device as would be appreciated by one skilled in the art, such as a display, a haptic device, a printer, speakers, and the like, to name a few examples. Furthermore, it should be appreciated that the input device 206 and the output device 208 can be combined to form a single unit, such as, for example, a touch-screen. While the output device 208 of the portable device 102 is described as providing a refined and/or ranked list of food items, it should be appreciated that other output devices separate from the portable device 102 can provide such a list. For example, the portable device 102 can be used to locate a user, while a separate electronic menu at a restaurant displays a list of food items specifically tailored to the user. The LDS 210 can include any type of system for location detection, whether hardware-based and/or software-based. For example, the LDS 210 can include a global positioning system (GPS), an assisted-GPS system, a compass and/or accelerometer, and other components for detecting the location or position of the portable device 102. In another example, the food database 104 can directly locate the portable device 102 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 with known locations through which the portable device 102 communicates. In another example, the location of the portable device can be determined based on the location of the Wi-Fi hotspot through which the portable device 102 communicates. A combination of technologies can also be used for location detection. For example, the portable device 102 can 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 location, such as when GPS line of sight is unavailable. The communication device 214 can include any type of device and/or software capable of communicating across the network 108. For example, the communication device 214 can include a cellular communication-type device, a Wi-Fi-type device, and/or an infrared port, to name a few examples.

In the above technology, the physician and/or patient are described as performing certain actions, but it should be appreciated that others may perform these actions in part or in full. For example, a physician's assistant, nurse, administrator, dietitian, and/or third party may perform the actions described with reference to the physician, and family members, nurses, assistants, employees, or other individuals may assist the patient in entering information into the portable device 102 or elsewhere. It should be appreciated that others may enter and/or prescribe a dietary regimen. In one specific example, the physician may mail or fax a form 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. As an example, imagine that a patient wishes to follow the South Beach Diet®, etc. Based on the patient's location, the system 100 highlights foods at locations that adhere to the diet. Later in this example, if the physician prescribes a different diet, the system 100 will override the previously selected patient diet to support the new dietary plan prescribed by the physician. Although physicians, other health care providers (e.g., dietitians), patients, and/or other individuals can assist in selecting a dietary approach in stage 302 ( FIG. 3 ), it is contemplated that the system 100 and technology can be used without selecting or prescribing a dietary approach. Even without selecting a dietary approach in stage 302, the user can still enter information such as meals consumed and blood glucose readings. However, assuming no dietary approach is specified, the system 100 will not be able to support reporting of dietary compliance metrics, but the system 100 will still be able to support other functions. In other words, even when no dietary approach is selected, the system 100 can still capture data and provide that data for structured testing purposes.

In providing information such as food, meals, dietary adherence, and restaurant information, it should be appreciated that system 100 at least emphasizes relevant information to simplify the user's selection process. As used herein, the term "emphasize" or any variation thereof (e.g., "emphasized") means pointing out and/or calling out relevant information to draw the user's attention so that the user can easily identify the relevant information. By way of non-limiting example, emphasis can be achieved by reducing the amount of information provided (e.g., limiting items on a list), ranking the information, filtering the information, sorting the information, highlighting the information, making the information stand out, underlining the information, increasing the volume when the information is displayed, and/or color-coding the 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 foods or meals are ranked based on how well the user adheres to the user's diet. However, other possibilities exist to help simplify the selection process. In an example using a hierarchical approach, restaurant names are first presented based on location. Then, upon selecting a restaurant, a hierarchical order of menu items or foods is displayed, with the previously selected item highlighted. It should also be appreciated that the interface may differ from that shown in the accompanying drawings. For the visually impaired, as well as 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, a display is used to interact with the user. As another example, a listing of food items may incorporate two tabs, one listing the meals and the other listing the individual food items. In order to customize and/or generate information about a particular meal, the user may combine one or more food items under the food item tab to create a meal. In addition, the user may manually enter meal information that does not appear in the food database 104.

The various stages of the above-described technique may be performed in a different order than that illustrated in the figures and/or described above. For example, in FIG4 , the menu of food items may be refined over time (stage 406) after the menu items have been ranked based on historical selections (stage 414). During the data capture and reporting stage 304, all or a portion of the information contained in the food database 104 may reside on the portable device 102. For example, in situations where network coverage for a smartphone is not readily available, the entire food database 104 may reside in the memory 204 of the portable device 102. Conversely, in situations where network communication is readily available, only the required information from the food database 104 is transmitted via the network and temporarily stored in the memory 204 of the portable device 102.

Although the present invention has been illustrated and described in detail in the drawings and foregoing description, they should be considered illustrative and not restrictive in character, and it should be understood that only preferred embodiments have been shown and described, and protection is desired for all changes, equivalents, and modifications that fall within the spirit of the invention as defined by the following claims. All publications, patents, and patent applications cited in this specification are herein incorporated by reference as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference herein in its entirety and set forth herein.

A method for obtaining information about food consumed by a subject undergoing blood glucose testing is disclosed, the method comprising: determining a location of a portable device possessed by the subject; providing the subject with a list of food items at least emphasizing food available at the location; receiving a selection from the list indicating a food consumed by the subject; and collecting a blood glucose reading from the subject.

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

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

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

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

In a development, the method further comprises providing, via the portable device, a metric showing the subject's compliance with the diet.

In a development, the method further comprises determining that the location lacks food items that meet the subject's dietary needs; and providing, via the portable device, a list of alternative locations that meet the subject's dietary needs.

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

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

In a 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 a development, the method further provides the subject with a list of food items including displaying the list of food items on a portable device.

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

In one development, the consumed food and blood glucose readings are stored along with a timestamp.

In a development, the method further comprises associating the consumed food with the blood glucose reading when the consumed food and the blood glucose reading occur within a defined time interval.

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

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

In a 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 a development, providing the list of food items to the subject includes emphasizing food available at the location by sorting the list of food items based on proximity to the user.

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

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

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

In a development, the method further comprises the step of prior to said outputting at least emphasizing a food item in said list based on how suitable it is for a specific time of day.

In a development, emphasizing food items in the list based on historical food preferences includes emphasizing food items on the list that were previously consumed by the subject.

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

In one development, the dietary regimen is prescribed by a physician.

In one development, the dietary regimen is selected by a user.

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

In a development, the method further comprises receiving information about meals consumed by the user, which is 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 disclosed development 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 possessed 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 to the portable device a list of food items emphasizing at least foods available at the location; wherein the portable device includes an output device configured to display the list of food items and an input device configured to receive a selection from the list indicating a 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 the blood glucose reading and information about the food consumed by the subject.

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

A system for obtaining food consumed by a subject undergoing a blood glucose test is disclosed, comprising: a portable device configured to be possessed by the subject; a location detection system configured to determine the location of the portable device; the portable device comprising: 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 at least emphasizing food available at the location; and an input device configured to receive a selection from the list indicating a food consumed by the subject.

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

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

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

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

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

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

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

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

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

Claims (20)

1. A method for obtaining information about food consumed by a subject undergoing a blood glucose test, the method comprising: Determine the location of the portable device owned by the object; Determine whether there is food available at the location that meets the dietary needs of the object, wherein if there is, the location is determined as a food source location, and if not, another location is selected as the food source location from the candidate locations by sorting the candidate locations with food items that meet the dietary needs based on their proximity to the object's location. Provide the object with a list of food items that highlight the food available at the location of the food source; Receive instructions from the list regarding the selection of food consumed by the object; and Collect blood glucose readings from the object. 2. The method of claim 1, wherein providing the object with a list of food items further comprises highlighting food items in the list based on the object's historical food preferences. 3. The method of claim 1, wherein providing the list of food items to the object further includes highlighting the food items in the list based on the object's dietary needs. 4. The method of claim 1, wherein providing the list of food items to the object further includes highlighting the food items in the list based on the time of day. 5. The method of claim 1, further comprising ranking food items on the list based on the dietary needs of the subject. 6. The method of claim 1, further comprising providing a measure of the subject’s adherence to the diet via a portable device. 7. The method of claim 1, wherein all the described actions are performed by a portable device. 8. The method of claim 1, wherein the recorded actions are performed, in whole or in part, by a food database located remotely from the portable device. 9. The method of claim 1, wherein collecting blood glucose readings includes receiving blood glucose readings from a glucometer. 10. The method of claim 9, wherein the blood glucose meter is integrated into a portable device. 11. The method of claim 1, wherein providing the object with a list of food items comprises displaying the list of food items on a portable device. 12. The method of claim 1, further comprising associating the food consumed by the object with blood glucose readings in a food database. 13. The method of claim 1, wherein the consumed food and blood glucose readings are stored together with a timestamp. 14. The method of claim 1, further comprising: associating the consumed food with the blood glucose reading when the consumed food and the blood glucose reading occur within a defined time interval. 15. The method of claim 1, further comprising triggering an alert system after a defined time period following the receipt of the selection. 16. The method of claim 1, further comprising providing the results of the blood glucose test to a computer of a healthcare provider. 17. The method of claim 1, wherein providing the list of food items to the object comprises highlighting food available at the food source location by filtering the list of food items to provide only food available at the food source location. 18. The method of claim 1, further comprising: Store blood glucose readings and the food choices consumed in memory; and At least process blood glucose readings and the choice of food consumed to identify any patterns in structured blood glucose testing. 19. The method of claim 1, wherein the receiving selection and the collection of blood glucose readings are performed at different times. 20. A system for obtaining information about food consumed by a subject undergoing a blood glucose test, comprising: A portable device configured to be owned by the object, the portable device having a location detection system configured to provide data indicating the location of the portable device; The food database is configured as follows: Determine whether food that meets the dietary needs of the subject is available at the location, wherein if it is, the food database identifies the location as a food source location, and if not, the food database selects another location as the food source location from the candidate locations by sorting candidate locations with food items that meet the dietary needs based on their proximity to the subject's location; and Provide the portable device with a list of food items that highlight the food available at the food source location; The portable device mentioned above includes: The output device is configured to display a list of food items; and An input device configured to receive an indication from the list of foods to be consumed by the object; A blood glucose meter configured to read a blood glucose reading from the object; and The food database is configured to store blood glucose readings and information about the food consumed by the object.