Considerations for selecting a dietary assessment system

Abstract

The software available with some food composition databases allows for the dietary assessment of individuals and groups and may provide graphic comparisons of nutrient intakes to dietary standards. Four factors to consider when choosing a computerized dietary assessment system are availability of desired database features, efficiency of the search engine in finding foods in the database, educational value of the output, and cost of purchasing and updating the software. Printed output should clearly characterize dietary adequacy with graphs or simple tables. Dietary assessment data used for research must also be available in electronic spreadsheet format for statistical analysis. Peer-reviewed papers in journals that provide overviews of the features of various computerized dietary assessment software are helpful for informing the selection process.

1 Introduction

Because the food composition database is a critical component of nutrient/food component calculation software, numerous peer-reviewed papers have compared this feature of dietary assessment software (Hoover 1983; Buzzard et al., 1991; Lee et al., 1995). The purpose of this paper is to review characteristics of current dietary assessment software, suggest criteria for evaluating software, and illustrate how these criteria apply to selected applications. Features reviewed are the database itself, how the database is searched, suitability of the output for research or counseling goals, and finally cost.

2 Software Features

Software generally manages a process. Dietary assessment software can manage the way one interviews a client, evaluates intake information, plans a meal, organizes a food service operation, or counsels a patient. Software facilitates counseling by guiding the dietary assessment process, evaluating composition of diet, and organizing information to support counseling goals. Software features differ depending on whether the primary aim is to support research or clinical practice. Applications developed for dietary assessment share many characteristics of other complex computer programs. Thus, new users typically require an orientation to the application functions and training in accessing and using program features.

2.1 The database

Food composition databases are commonly categorized as either reference or user databases (Braithwaite et al., 2006). Reference databases are compiled and distributed by the government or other authoritative body. Databases compiled by software companies to accompany their products or by individuals for use in specific clinical or research activities are referred to as user databases. The database is an essential part of dietary assessment software. Validity of assessments produced by the software depends on the quality of the food component data. Potential users should evaluate food names and descriptions and whether the food component data is representative of foods available to the population being surveyed. Precise food names and descriptors help ensure that the associated data correspond to the food for which information is sought. For example, a beef stew may be specified as gravy- or tomato-based and containing carrots or other vegetables to accurately capture food components such as carotene and/or lycopene. Sometimes a food name is ambiguous or even elusive, for example, a hamburger bun may be called a roll, making it difficult to find. Even spelling sometimes hinders a food search, such as ketchup vs. catsup or donut vs. doughnut. Non-US databases introduce another level of difficulty for US users even when the foods names are in English. For example, cornmeal may be called masa harina or maize flour outside the US. Food names need to consider common usage and regional variation, as well as standard nomenclature. For example, it is useful to include a generic name such as breakfast pastry to lead users to appropriate substitutions for items such as kolache, monkey bread or Danish when these items are not listed on the database by the name used by consumers. Practicing with a software demonstration version is a good way to examine the food names available in the database.

Data quality refers to appropriateness of the food values, meaning that the values are representative of the composition of the foods specified on the database, and the foods on the database are those that are eaten by the population served. The term “accuracy” seems easy to understand, but on close examination it becomes a relative concept. Users expect the food composition data to be accurate for their purpose, which might be to estimate food component intake of clients in the eastern, midwest, or western states and at any time of the year; or it might be expected to represent the composition of specific foods to be served from a metabolic kitchen. It is unlikely that a single set of values for a food will match the data needs in all situations. Fruits and vegetables have a variable composition due to differences in maturity, length and method of storage, variety and method of analysis (Davis et al., 2004; Hecke et al., 2006), but typically only one value for each food component is provided in a database. Representative sampling takes such variability into consideration so that published values reflect geographic region, season, cultivar, and other factors that affect composition. Foods in the United States Department of Agriculture (USDA) Nutrient Database for Standard Reference (SR) (USDA NDL 2006) often have qualifiers such as “year-round average.” Standardized products produced under strict quality control may be more consistent in composition than food produced in homes or restaurants. Because some standardized products are widely consumed, some data users may seek databases featuring up-to-date food composition values from large corporations and chain restaurants. Users must recognize limitations of the data and use judgment when reporting food component estimates.

Food Composition databases require frequent updates to keep pace with new, reformulated and discontinued items in the market place and to keep pace with advances in food analysis methods. The USDA SR is updated about once a year and most software developer are quick to incorporate updated values into their software. The basic sources for data in the U.S. would likely be the SR or the USDA Food and Nutrient Database for Dietary Studies (FNDDS) (USDA FSRG, 2006a). The addition of foods and food component values to the user databases to complement or update the USDA values, should be done by personnel who are knowledgeable about the variability surrounding food composition data, are able to evaluate and make informed judgments about the accuracy of the data, and are knowledgeable about making calculations to convert label data to database values. Further, values that are added should be current for products on the market (commercial foods may change over time), and database quality assurance should be conducted to ensure that inadvertent errors have not been introduced when the database was constructed or updated.

Buzzard et al. (1991) outlined useful guidelines for evaluating database features:

1. Does the database contain all of the foods and food components of interest?

Software product literature will list available food components, thus facilitating evaluation of this criterion, but whether or not appropriate foods are available is more difficult to determine. One criterion for selecting a database is to choose a data source that represents foods available to your study or dietetic practice population because food names, varieties grown and distributed, typical recipes, and fortification rules and practices differ by geographic region and national boundaries. For example, calculation of food energy differs between the U.S. and Canada, two neighboring countries. In the U.S., the factors 4-9-4 are used to determine energy from carbohydrate, fat and protein, respectively, minus the energy represented by the carbohydrate content of dietary fiber. In Canada and most of the rest of the world, the adjustment for dietary fiber is not made. In the U.S., the data source might be the SR (USDA NDL 2006) or the FNDDS (USDA FSRG 2006a), whereas Canada maintains their own national database. As the name suggests, the SR is the standard U.S. database with many applications. The FNDDS is composed of approximately 2700 of the 6000+ SR foods plus many more foods added to support the U.S. national food consumption survey (http://www.ars.usda.gov/Services/docs.htm?docid=15044).

2. Is the database complete for all food components of interest?

This question is often difficult to answer. Detailed specifications are readily available for the SR (USDA NDL 2006) and FNDDS (USDA FSRG 2006a). Table 1 compares the food components available and percent of foods that have values for each component for these two databases. Because the SR lists only available values and does not provide zeros even when nutrients are known to be absent from a food (such as fat in table sugar), some food component fields are empty. In the FNDDS, all food component fields have a value, either a zero when a food component is probably absent or an estimated value using imputations. The International Nutrient Databank Directory, sponsored by the National Nutrient Databank Conference, contains information on available food components for over thirty databases (Braithwaite et al., 2006). The Directory is updated every 2 or 3 years.

Table 1.

Percent of foods with values for food components in the USDA databases, Standard Reference (SR), Release 19¹, and Food and Nutrient Database for Dietary Studies (FNDDS), Version 2.0²

Food Components	SR-19	FNDDS 2.0
Energy and macronutrients (carbohydrate, protein, fat, water)	100	100
Alcohol	58	100
Dietary fiber	90	100
Cholesterol	97	100
Other sterols, n=4	3	-
Total sugar	65	100
Individual sugars (n=6 incl.: lactose, sucrose, maltose, fructose)	11	-
Vitamins, vitamin precursors, fortificants and calculations (n=16)	82	100
Other vitamins & precursors (n=12, D, betaine, added Vit E, etc)	34	-
Minerals (n=10, calcium, zinc, sodium, etc.)	93	100
Fluoride	7	-
Fatty acid classes (saturated, monounsaturated, polyunsaturated)	94	100
Fatty acids, saturated (n=8: 4–18 carbons-even numbers.)	74	100
Fatty acids, saturated (n=6: 13, 15, 17, 20, 22 and 24 carbons)	10	-
Fatty acids, monounsaturated (n=4: 16, 18, 20, 22 carbons)	96	100
Fatty acids, monounsaturated (n=8: other isomers)	3	-
Fatty acids, polyunsaturated (n=7: 18 (n=3), 20 22 (n=2 of each))	70	100
Fatty acids, polyunsaturated (other isomers, n=15)	3	-
Fatty acids, trans, total	10	-
Amino acids, n=18	64	-
Amino acids, hydroxyproline	9	-
Caffeine, theobromine	54	100

¹USDA NDL (2006)

²USDA FSRG (2006)

^-= not available

Note. Percentages for many food components in SR are not available because these components are not present in the food and therefore analytical values are not available Examples are alcohol or total sugar in beverages containing zero calories, or fatty acids in foods with no fat. These food components are an “assumed zero” in the FNDDS.

3. Do the food descriptions included in the database provide adequate specificity to accurately assess food components of interest?

This question is probably the most difficult to assess without actually using the software. An important factor to consider is whether your purpose requires information about special items such as low-fat or low-sodium versions of food items and whether they are available on the database or if the software allows you to enter these items yourself (albeit a labor-intensive solution). Of greater concern is the way manufactured foods are incorporated into the database. While data from industry for standardized products is convenient, users should be aware that data from the manufacturer typically include only nutrients found on the food label or that are required for nutrient claims or for educational materials published by the company. When the food label is the source of food composition data, many food component fields will be left empty. For example, a generic food product on the SR database may have data for manganese and choline but the comparable product packaged and labeled by an individual company may have no data for these components either on the label or from data sheets provided by the manufacturer, not because they are not present in the food, but because that particular brand of this food has not been analyzed for those components.

4. What quality control procedures are used to ensure the accuracy of the database?

Users generally rely on the reputation of the software developer for this criterion. Quality control procedures for a database include simple comparisons such as whether the total fat is greater than the sum of the individual fatty acids for each food. An error in this calculation would alert the developers to a possible data error. Ahuja et al. (this issue) describe typical quality assurance procedures used during development of the USDA FNDDS database.

2.2 Search strategy

Finding foods in a database is much easier now than when foods were accessed by code numbers. We now expect to find the food we want quickly, by entering the food name into the software program.

It is important that search functions allow for searching for more than one word at a time in the food name or description. For example, when searching the FNDDS for a fresh tomato, you find different lists depending on how the program conducts the search. Using the on-line search tool (USDA FSRG, 2006b) for tomato finds 337 items, from ripe and canned tomatoes to salad dressing or pasta with tomato. Scanning this list for the desired entry would be time-consuming; however, if you search for tomato raw, the list is quickly narrowed to only 3 items. Most programs in use today allow more than one word in the search, and in any order.

ProNutra (Viocare, 2006) adds a unique feature to this function, by allowing the user to enter a complex algorithm into the food search. For example, if a user is developing a ketogenic diet with 80% of the calories from fat, the program allows a food search using an algorithm such as kcal/fat g to locate individual foods with at least 9 g of fat (~81 kilocalories) for every 100 calories. Using this algorithm, foods such as solid fats, bacon, cream, cream cheese, sausage, nuts and olives are located (they have a value of 11.1 or less, the reciprocal of the grams of fat required for each 100 calories).

The number of foods in the database is certainly one indicator of the database’s resources, but the number of foods alone is not a guarantee that the appropriate foods are available. Combining the foods of two different databases into a single database might double the number of foods, but there would be much unnecessary redundancy.

2.3 Output

For many if not most applications, the important information is the sum of levels of food components present in a list of foods, as in a recipe or meal, or foods eaten during one day or averaged over more days. For menu development, the composition of foods planned for a meal may be the key data, whereas for an intervention study it may be the composition of foods eaten over several days. Users need to be sure the system can summarize the data by day, meal or menu, depending on how it will be most useful to them.

If printed material is needed for educational purposes, the printed output should be simple and concise. Graphs are useful to illustrate nutrient adequacy, and will allow users to select components key to interventions. Figure 1 shows a bar graph that illustrates sources of potassium in the diet as an example of a focused summary that could support a counseling goal.

Fig. 1.

Graph illustrating contribution of 100 gram portions of different foods to the potassium content of the diet.

Occasionally a list of foods eaten, with a tabular display of critical food components, may be used for educational purposes (Figure 2). However, such displays more often than not, are too complex for clinical work. Introducing one or two components might help accomplish a counseling goal, such as carbohydrate and calories when counseling for control of blood sugar or weight loss, or sodium, potassium, and phosphorus when counseling for a renal diet. Caution must be exercised, however, when using large data printouts in a counseling situation lest the message becomes too complex. A display with hundreds of individual values seldom accomplishes a useful purpose in counseling. Figures 3 is a graph that illustrates dietary adequacy from a contemporary program comparing intake to a nutrient standard, the Recommended Dietary Allowances (RDA) and/or Adequate Intake (AI) (Otten et al., 2006).

Fig. 2.

Food component data for 100 g portions in spreadsheet format showing detailed nutrient information and extent of missing values for selected components. (Dash indicates missing values; note values for biotin and chromium are sparse)

Fig. 3.

Graphic printout comparing total intake to Recommended Dietary Allowances (RDA), (Food Processor, ESHA, Salem, Oregon).

When an educational goal involves overall nutrition, the more consumer-friendly display might involve food groups rather than individual food component values. Figure 4 is one attempt to use MyPyramidTracker (USDA, 2005) recommendations as an evaluation tool. Figure 5 compares intake to a nutrient standard as percents and as the probability of adequacy. The probability approach evaluates intake using a range from 0 percent (probably not adequate) to 100 percent (probably adequate) (Otten et al., 2006, Stumbo and Murphy, 2004). A recent summary of the Dietary Reference Intakes discusses appropriate comparisons of nutrient adequacy and suggests that a probability approach is superior to the more traditional percentage approach (Otten et. al., 2006).

Fig. 4.

Bar Graph comparing intake to the USDA Food Guide Pyramid. (MyPyramid Tracker, www.mypyramidtracker.gov).

Fig. 5.

Illustrates two potential graphic displays, the upper, lighter bars show percent of the RDA provided by foods and the lower, darker bars show probability of adequacy.

For research purposes, results may be exported to a spread sheet format to facilitate custom summaries and statistical analysis. Note that the spread sheet format in Figure 2, while generally not suitable for educational purposes, is useful for calculating averages and correlations and making other statistical comparisons.

2.4 Cost

Cost is another important consideration when selecting dietary assessment software. While the FNDDS and SR databases are free, many software applications that use these data for dietary assessment are not. Some applications have been developed using public funding, and others have been developed privately (Table 2). Those based on public funding addressed research needs where there was a limited financial return; whereas those that developed privately did so in response to clinical and commercial needs. Both types of software have garnered a loyal following of satisfied users and are supported by user fees. The five programs in Table 2 illustrate the cost differential among software. The costs represent financial realities and do not necessarily reflect the quality of the final product.

Table 2.

Original funding source and relative cost of selected software

Program Name	Initial Funding	Cost
Food Processor	Private	~$600
Nutritionist Pro	Private	~$600
Nutrient Data System for Research (NDS-R)a	Public	~$8000
ProNutraa	Public	~$3000
Food Intake and Analysis System (FIAS)a	Public	~$6000

^aInitial development supported by The National Institutes of Health or United States Department of Agriculture; currently all are supported by user fees. These systems fulfill specialized research needs for a limited user base, resulting in higher development and maintenance costs per user.

The size of the user base directly affects cost because more users translates to more development income and thus to lower software price. There are many more clinical users than research users, and these numbers have a direct impact on cost. Food Processor (ESHA Research, 2006) and Nutritionist Pro (Axxya Systems, 2006) are priced under $1000 and used extensively for both clinical and research purposes (Table 2). The Nutrient Data System for Research (NDS-R) (University of Minnesota, 2007), ProNutra (Viocare, 1996), and the Food Intake and Analysis System (FIAS) (The University of Texas, Houston, 2006) were developed to support a research need and cost several thousand dollars (Table 2). (See Braithwaite, et al., 2006 for description of these and other software programs.)

NDS-R was originally developed to support National Heart Lung and Blood Institute research with emphasis on fat and fatty acid values for foods eaten by study participants at home and away from home (Feskanich et al., 1988). Other components needed for studies funded by the National Institute of Health such as fluoride and glycemic index/load have recently been added to the NDS-R. The NDS-R database has extensive food component values for brand name food products with values for 100+ components; values are imputed if not available from the literature or manufacturer. ProNutra is another application designed for research. It uses both the USDA SR and FNDDS databases and was developed to support metabolic feeding studies where diets of specific composition are developed. One of its unique features is advanced search strategies permitting the search for single food components values. Another feature is the ability to search for values expressed as a proportion such as foods high in potassium while also being low in phosphorus. Other research-specific functions are grouping output by study name or by study period and calculations of diets-as-planned or diets-as-consumed. FIAS was developed to provide researchers with dietary assessment methodology comparable to that of the national food intake survey. It is unique in the way it incorporates the FNDDS database and includes multiple files that support the FNDDS database such as retention factors and common recipes, making this information available to the user to facilitate customizing foods as they are entered into the database. These unique features are important with regard to cost; if they are not needed then a lower cost alternative can be considered.

3 Discussion

Mastery of computerized dietary assessment requires an understanding of the database in terms of the naming conventions, the search strategy for finding foods, and data completeness for generic and brand-name foods.. If the dietary assessment requires information about food components that are sparsely incorporated into the database, it may be better to link the consumed food to generic foods (with more complete profiles) than to brand name foods (with less complete profiles). For example, if an entry for a Swanson Chicken dinner does not include values for selenium or another value of interest, then the three main components (baked chicken, mashed potatoes and corn) could be substituted in appropriate amounts to match the carbohydrate, protein, and fat content of the packaged meal as found in the database. This technique is labor-intensive but has been used in some databases to fill in gaps in the data, such as is done for the NDS-R database and for earlier versions of the Nutrient Database for Nationwide Dietary Intake Surveys (Schakel et al., 1988; Perloff et al., 1990).

4 Conclusions

Choosing software that has the functions needed to accomplish an assessment and practicing to gain skill in locating appropriate foods in the database will improve accuracy of the assessment and utility of the information generated. Finding software that generates reports to complement teaching objectives or designing materials to illustrate important information from the food intake assessment is the final step in dietary assessment. A useful tool for comparing databases and software functionality is the International Nutrient Databank Directory (Braithwaite, 2006). Software reviews are also helpful for informing the selection process.