Subjects Archives - CANDAT

Foods that we eat and their relationship to health

Main menu

Week-weighted Averages in CANDAT

When expressing and comparing results of multi-day (3 day commonly) food recalls one tends to use the average daily intake as a measure of a subject’s intake. Of course, 7 day recalls will give more accurate estimates of this daily intake and the accuracy will increase if all the days of a week are used. The assumption here is that subjects will eat differently on different days with the greatest variability been between week days and weekend days.

Rather than simply computing an average daily intake one may get more accurate results by weighting the days of the week and the weekend days differently.

A weight of 5 for each week day and a weight of 2 for weekend days should allow us to calculate week-weighted averages for any number of recalls. Of course, for recalls without weekends this would just be a day of the week average and vice-versa.

The week-weighted average could be calculated as follows:

x_w = (∑ w_i × x_i) ÷ ∑ w

where x_w is the weighted average with x_i as the daily intakes, and _i is 1 – 5 (codes for days of the week) or 0,6 codes for weekend days corresponding to Sunday and Saturday respectively. w_1-5 would then be 5 and w_0,6 would be 2.

with a variance of

Var(x_w) = Var(x) × ((∑ w_i²) ÷ (w_i)²)

where Var(x) would be the variance over all the days of the food intakes for the subject.
University of PEI

CANDAT is superior to other nutrient analysis programs because it is designed to accommodate the diverse needs of researchers. Being able to handle food recalls and records and food frequency questionnaires in the same program, to create user files of special food items not included in the CNF and to easily import files into statistical analysis packages makes it unique in Canada. Most of all, having a support person who has extensive experience with nutrition researchers makes CANDAT an easy choice for me.

I have been working with CANDAT since 1984, and have also tried a number of other nutrient analysis programs. I keep coming back to CANDAT for two reasons: the support with CANDAT is superb. I have emailed Gaetan and received a phone call within minutes. He “knows his stuff” and can pinpoint and resolve any problems or challenges quickly. The program he uses to take over the computer is amazing and very efficient.

Since he has worked with a number of academics in nutrition, he understands research and the special needs researchers have. My research group had a challenging task a few years ago which involved adapting an American Food Frequency questionnaire for Canadian use and adding data on dietary nitrates. This was a very complex and time consuming task, and Gaetan was an active participant in the research process. When we were under time pressures to complete the analysis, Gaetan committed time and was able to get us the data when we needed it. He goes beyond a technical role, and sometimes poses questions which I don’t think of, preventing problems before they happen.

Dr. Jennifer Taylor, Associate Professor & Chair
Department of Family & Nutritional Sciences
Dalton Hall 204
University of Prince Edward Island
550 University Ave, Charlottetown PEI C1A 4P3 (902)
566-0475 Fax (902) 628-4367
Food history questionnaires
A lot of nutrition research is done through the use of the food history questionnaire. This is different from food recalls in that it is shorter, easier to administer and does not require special interviewing skills.
Sometimes studies need to identify patterns of food consumption in a large population. This is done, for instance, as part of a general population health survey. These are done on a fairly regular basis, usually funded by governments, to be proactive in the formulation of heath related polices. This saves our tax money in the long run.
Food history questionnaires are related to food recalls in that they collect information on commonly eaten foods. These questionnaires tend to be simpler in that they do not seek to know each individual food that was eaten. They ask questions like “When you eat pasta how much do you eat and do you eat it once a week, or 3-5 times a month”. You get the idea. Typically a food history questionnaire will have fewer than 100 such questions.
Before a questionnaire like this can be formulated it is wise to know what kinds of foods the population usually eats. A smaller number of individuals are asked what they ate recently, using the recall format. Using the example above, from the results of these recalls, a pattern of “pasta” consumption can be determined. A composite “pasta” food can then be created and used as the nutrient profile for the “pasta” question in the food history questionnaire.
The downfall is that it is a fairly “blunt” instruments. With a bit of care in its construction some of the bluntness can be removed.
The following techniques can be used to make them better research instruments:
- Make up your own;
- Make them specific to your target population;
- Make them as detailed as possible while keeping them still realistically long;
- Base the questions on foods your population eats. Collect as many food recalls as you can and base the questions on the foods in those recalls;
- Create composite foods from similar foods in the recalls and use those to calculate nutrient contributions for corresponding questions in the food history questionnaire;
- Validate your questionnaire… does it over/under-estimate specific nutrients in comparison to your food recall data?
There is enough variability in food intake and nutrient concentrations of individual foods to try to minimize the effect of further variability introduced by blunt food history questionnaires.
Given the amount of variability in this data it is a wonder that any conclusion can be reached about the predicted effect of a nutrient intervention or of specific nutrient consumption.
By all means find and use good software that will make your task bearable. Variability can only be reduced by eliminating mistakes, using the best sources of data possible and collecting large amounts of data. A significant task indeed.
Questionnaire concepts
A subject’s nutrient profile, whether obtained from food recall information or from food history (questionnaire) information, is obtained by a simple arithmetic calculation. Each nutrient is the product of the food quantity consumed and the nutrient’s concentration in that food. The subject’s consumption is the sum of these products over the foods consumed in one day. Simple.
Problems:
In a recall… using the right food code to represent the food consumed and estimating the quantity consumed as accurately as possible. For a recall there are thousands of food codes to choose from, one of those is likely to represent fairly accurately the actual food consumed. The quantity of that food consumed can also be fairly accurately recorded as reported.
An example of a recall record would be “I ate a banana for breakfast”. The corresponding coding would have the food code for bananas and quantity being typically “one medium banana”. Hence, nutrient profile and quantity fairly accurately recorded and yield fairly good nutrient information.
In a questionnaire very few questions (usually less than 200, sometimes as few as 100) are used to represent historical intake. Every question is matched to a food with a nutrient profile representing the consumption for that question. A single food taken from a database used in recalls is not likely to be indicative of the group of foods represented by any one question in the questionnaire.
An example question could be “Do you consume soup?”. There are many soups with different nutrient profiles. Which one to use for the question as a nutrient profile? The soup code used should be a “composite” of all the possible soups. Which composite to use? One formed of the relative use all the soups consumed in the population in question. This information can be obtained from a food recall study of the population. This “composite” food could then be taken as the food representing the question’s nutrient profile… a good estimate on a population basis, probably not so good on an individual basis.
Composite food calculations from food recalls:
- Determine the unique food codes from all the recalls. Typically should be 400-600 food codes
- Divide those codes into food groups corresponding to questions you would want in the questionnaire
- Run the nutrient calculations on the recalls looking at food details by food group, sorted in descending order of food quantity in grams
- Create a recipe from each food group using the main foods in that group and their corresponding quantities as recipe ingredients
- Run the nutrient analysis on the recipe file and export each recipe and its nutrients per 100G to a food file
- Use this food file in your nutrient calculations of the relevant questions
Of course, this assumes you have the software to do all these calculations and conversions automatically. Doing the calculations manually or using a spreadsheet would be very onerous indeed.
The question of quantity to record is a bit more difficult. Usually such a question asks “How often do you consume this soup? Per day? Per week? Per month?”. No problem here, just a mathematical calculation.
The problem is in the next part of the estimate, the portion size. If the portion size is indicated precisely as in .5 cup, 1 cup, 2 cups… again, no problem. The composite soup can have a weighted density based on the density of the soups making up the composite. Cup weights can then be precisely calculated. 250 ml x 1.06 G/ml would give us a cup weight of 265 G.
Technique A:
How does one estimate portion sizes when the portion is not so precisely indicated? As in, .5 of a cup or less, .5 cup to 2 cups, 2 cups or more? One logical estimate would be to take the mid-point of the ranges.
For minimal consumption to .5 cups, use .25 cup;
for .5 to 2 cups, use 1.25 cups; for 2 cups or more use 4 cups (maximal consumption assumed to be 6 cups).
Technique B:
Much more intensely computational… not using the composite weighted densities…
An alternative to the above would be to use population based estimates. For each of the range of consumption, .5 cup or less, .5 cup to 2 cups and 2 cups and more, establish the distribution of consumption and calculate the median or average value. The median value would probably be best as it would negate the effects of outlier consumption.
In the population there is no consumption of the composite soup. The distributions have to be calculated for each and every soup making up the composite. One median per soup! For example for the lower range, less than .5 cup, how does one obtain a composite median from the individual soup medians? A weighted average of medians? Based on what weighting factor? The relative weight of the total weight of the soup consumed in the population (used to get the weighted density of the composite) or the relative weight of the total weight consumed in the range less than .5 cup? I would guess the latter to be the better estimate.
How does one establish the cut-off weight for .5 cup. The best value would be obtained by using the density for the soup whose median is being calculated. If the soup has a density of 1.06, one would look at all consumption of that soup of .5 cup or less or of 265G/2 = 132 G or less. The range .5 and above would start at 133G…
Should the basis of the distribution of consumption be each consumption of soup or the total soup consumption for the day? This question may not seem relevant here (each consumption would be the best information for the typical portion size) but what about other foods, such as milk in all its possible consumption portion sizes (see below)?
Assumptions:
Technique B assumes that all consumptions recorded in the population recalls are based on portions that are cups. In soups this is probably reasonable. What about questions that ask questions about foods such as milk. “Do you consume milk?” If yes, how many times per day/week/month and how many glasses? Recalls will record all kinds of consumptions of milk. In cereal, in coffee or tea, in glasses or cups. Each one of these will be converted to Grams. The total of those consumptions, on a daily basis, or on a per consumption basis, may not reflect typical population median gram values for typical glass or cup portion sizes.
Estimates of portion sizes for questionnaire data should be based on recall data collected using those same portion sizes.
Food frequency questionnaires

Sometimes studies need to identify patterns of food consumption in a large population. This is done, for instance, as part of a general population health survey. These are done on a fairly regular basis, usually funded by governments, to be proactive in the formulation of heath related polices. This saves our tax money in the long run.

Food history questionnaires are related to food recalls in that they collect information on commonly eaten foods. These questionnaires tend to be simpler in that they do not seek to know each individual food that was eaten. They ask questions like “When you eat pasta how much do you eat and do you eat it once a week, or 3-5 times a month”. You get the idea. Typically a food history questionnaire will have fewer than 100 such questions.

Before a questionnaire like this can be formulated it is wise to know what kinds of foods the population usually eats. A smaller number of individuals are asked what they ate recently, using the recall format. Using the example above, from the results of these recalls, a pattern of “pasta” consumption can be determined. A composite “pasta” food can then be created and used as the nutrient profile for the “pasta” question in the food history questionnaire.
SPSS or SAS or PSPP or … and CANDAT
SPSS, SAS (or other good statistical packages) is used to process Candat calculations into results for your scientific report.

At its most detailed Candat will produce data files consisting of:
- Subject code
- Date
- Day of Week code (0-6, where 0 is Sunday)
- Food Group code
- Meal code
- Food code
- Food description
- Nutrient variables (Weight of foods and all nutrients you selected at reporting)
The printed (text or PDF) file (hopefully you did not print to paper) can have all of the above information as well as basic statistics (for a quick perusal, not meant to be used instead of a statistical package).

Candat also produces computer readable files that can be directly read into statistical packages or spreadsheet software (such as Excel or Open or Libre Office Calc or ….) . . Your study will probably want to make use of daily average intake data, as representative as possible of your subject’s usual intake.

Where you have days of the week and weekend days you will probably want to make use week-weighted average daily intakes, where weekend days carry less weight than week days. These week-weighted averages are calculated in Candat but should be re-calculated in the statistical package so that you can make use of the proper variance calculations for weighted data.

Systematically then here are the procedures to follow for managing your data:
- Generate the data in Candat you need in a compact way. If you are not interested in data by meals or by food group or at the food detail level, leave those out of the Candat calculation.
- Read the Candat generated file into a statistical package
- Identify missing data as -1 (the Candat value at the food level. In Candat summaries (means) missing values are considered a zero. This makes sense because food databases do not spend much time analyzing nutrients that are not likely to exist in the food but they do not report them as having a value of zero (usually).
- Convert the Day of Week code to a weight to be used in week weighted calculations. In Candat we use 5 for codes 1 to 5 and 2 for codes 0 and 6.
- Weight the cases using the converted Day of Week variable
- Aggregate the cases. In most cases you will want to aggregate the data using Subject code and Date code as independent variables, an average weight code for the weighting variable (average will maintain the weight code for the day) and sum (which adds up all the contributions for that day) for the nutrient variables. At this point your data is ready for statistical processing.
- Apply exploratory statistics to all your variables and make sure the data seems reasonable
- Merge the data variables that identify your subject variables. This may be from a file produced externally from Candat or from the Candat Description file. In either case you must make sure to merge on the Subject codes.
- Compare your subjects to your control groups (subject variables) using statistical procedures and save the results.
Report these results, write the other sections of the paper and you are done.
Course & Documentation

Please follow the outline in the column on the right to navigate through food research techniques and documentation on using Candat with those techniques.

Please enjoy the site and all its information.
Recipes & CANDAT
Recipes are another source of food information. Not all foods can be found in food databases, There is a limitless number of recipes and thus a limitless number of foods. You only need to look at the number of recipe books that are available to have an idea of the number of foods that are possible.

A good study needs to be able to identify commonly used recipes in the target populations and find suitable foods to code for those recipes. Where there are no suitable codes, the ingredients of the recipe need to be identified and a suitable food defined from these ingredients. CANDAT has tools to do this and to manage the consequent data

The following are the two menu selections needed manage the tasks in the recipe module.

This from the main CANDAT menu and

this from the choices then presented:

The standard startup choices below are presented after the selection of a task and

are explained in . The prompts that follow activating “START the task” control the options for the task in question and are explained in the appropriate task chapter.

The list of tasks in the task menu area are listed in the order one would use them. More detailed information about each task can be found in that task’s chapter.
1. 400 Recipe file maintenance – this is where recipes are defined, copied, modified, listed, etc.
2. 410 Recipe file validation – once recipes have been created this task validates that the ingredients exist and that proper units have been specified for quantities
3. 420 Recipe nutrient calculations – nutrients are calculated for each recipe and listed on a total and per ingredient basis. Ratings of recipes based on system Recommended Daily Intakes (RDI) are listed here as well
4. 430 Recipe to food file conversion – to use recipe data as part of subject recalls or even as ingredients in other recipes, they must be made into foods using food files. The foods in these food files can then be used as input to subject data or recipe data and managed like regular food files
5. 100 Food file maintenance – this task is part of the food files module. It is included here as a convenient link to food files once recipes have been converted to foods
6. 440 Recipe reports by types – part of the definition of foods has optional fields which define attributes of the recipe. The reports in this task allow listing of recipes that satisfy those attributes.
Task 400 – Recipe Maintenance
This task begins by prompting for the file name. Files that exist already will be listed and the one desired selected. If the new… choice is selected a new file name needs to be entered. New file names must start with a letter, have no spaces within the name and have 8 characters (letters or numbers) or less.

Recipe files can contain the definition of many recipes. Each recipe is identified by a code of up to 7 digits. As recipe files may eventually be converted to foods it is a good idea to use the same convention for their codes as are used for food codes.

A food code is entered here. If the code exists already, the next prompt will be the options prompt where the recipe information can be modified. Otherwise a message will appear prompting for the creation of a recipe. Again, the options prompt will appear allowing the entry of recipe information.

The various parts of a recipe can be defined using the recipe options listed here. The ingredient editing options change the same ingredient data, there are two ways of editing these for convenience.

Attributes define a recipes profile. There can be two preparations for each recipe to be used as desired. Some will use preparion one for imperial units and preparation two for metric units. Some will use preparation one for a recipe with a small number of servings and preparation two for a much larger number of servings. Each preparation has its own profile and its own quantities for each ingredients. Other uses of preparations are up to the imagination and needs of the user. Of course, a single preparation can be used as well.

The fields defining a recipe are as follows:
1. Recipe name: A description for the recipe. Remember this will also be used as a description for the food if the recipe data is ever converted to a food.
2. Remarks: Any remark specific to this recipe. It serves as additional documentation to the recipe and is not used in conversion to a food and is an optional field.
3. Hints line 1::Any hint specific to this recipe. It serves as additional documentation to the recipe and is not used in conversion to a food. Also an optional field.
4. Target % H2O: This is used to compensate for cooking method. The recipe nutrient data will be adjusted to force this % moisture in the final recipe. It consists of a single number like 8.5 or 10 or 33.8, etc. It this field is not used for target moisture it can be used for additional hint data and is an optional field.
5. Where used:,Product Group:,Main Product: These are arbitraty and optional descriptions used to further define the profile of recipes. To use these fields as selectors in future report groupings a consistent set of descriptions must be developed and used.
6. Number of servings: A number, required to calculate nutrients per serving.
7. Serving size: Specified in grams.
8. Unit of measure: This is always 0, the unit code for grams.
9. Density: If known, is entered here as a number of grams per 100 ml. Is used in conversion to food. A food with a density can be used with volumetric units.
10. Dates: The date created is automatically entered here. The other dates are optional and can serve as record keeping to monitor the progress of the recipe through its phases. Dates are entered using the format yyyymmdd.
11. Recipe Type Code: These codes are arbitraty and optional and can be used as selectors in future report groupings. This requires a consistent set of descriptions to be developed and used
12. Preparation Time (mins): A number of minutes, again, used as selectors in future report groupings
Ingredients are inserted and modified using either of the two following panels. Fields describing each ingredient are:
1. Ingredient code: Ingredient codes come from food files and must exist there before they are used. Food codes for ingredients are found using the F6 information key with a keyword search term. Multiple keywords can be used. If seperated by spaces each keyword must be present, separated by commas, one or the other keyword can be present. The result of the search is a list of foods satisfying the search parameters. Choosing the desired food inserts its code in the ingredient code field.
2. Unit code: This code is specific to the ingredient and a list of possible codes are accessed using the F6 information key. Choosing the desired unit code inserts its code int he unit field.
3. Quantity: This is the quantity of the ingredient required for the recipe in “unit code” units.
4. The E/F and the % Yield fields are not presently used and are reserved. The concept behind the E/F field was as an “each” parameter as in each of the servings would have this quantity of the ingredient. The total quantity of the ingredient would thus depend on the recipe’s profile information.
The above panel consists of multiple lines of entry per ingredient. As you tab from field to field you will see the space highlighted for each.

The above panel consists of a single line of entry per ingredient. Again, As you tab from field to field you will see the space highlighted for each.

The preparation panel is used to describe the preparation of the recipe. It is mostly meant to be used in managing cookbooks and is not used in the conversion of recipes to food codes. It consists of arbitrary text and it too is an optional field.

Once all the data has been entered pressing the Esc key will save all the recipe data automatically and navigate back to the previous step or menu.
Recipe – Validation

One of the purposes of creating recipes is to be able to calculate their nutrient profile. If you were doing this manually you would look for the nutrient profile of each ingredient and sum each ingredient’s nutrient contribution. From this you would get an estimate of the recipe’s nutrient profile.

Validating a recipe is a step that ensures, in an automated system, that all ingredients are present in the food database. The nutrient calculation of the recipe can then proceed automatically. Validation will report either that the ingredient does not exist or that the units used to quantify the ingredient are not valid. In either case one must correct the mistake before instructing the program to calculate the recipe values.
Recipe – management
A database of recipes needs to be managed. Management means the following:
- Being able to list the recipes (simple code and description only)
- Being able to list the recipes with contents. This allows verification of information entered to ensure accuracy
- Being able to copy recipes to other recipe databases to save re-entry
- Being able to delete recipes no longer relevant
- Being able to copy a recipe into another recipe. This allows creating variations on a recipe without having to re-enter all the duplicated information
This management is best done by computer programs. Recipe database files can then be easily stored, backed-up and shared with others.
Recipe – Input
There is more to recipe input than just entering the ingredients and their quantities. Below is a list of requirements to define recipes. (R) indicates a required item, (O) indicates an optional item but useful if you are going to be creating a large collection of recipes for many purposes.
- (R) A recipe database. If a database does not exist, it must be easy to create one.
- (R) Recipe code. The unique identification for the recipe. One can build in some information in this code, for instance, all 100 recipes could be salads, all 500 recipes could be deserts, etc.
- (R) Recipe description. This is the name of the recipe.
- (R) Ingredients. A list of ingredients with quantities. Each ingredient is a food code from the active food database. Quantities of each ingredient are specified in grams.
- (R) Number of servings. How many servings does this recipe produce.
- (R) Serving size. This can usually be derived from the sum of the ingredients weights and the number of servings. If the recipe loses moisture in cooking the serving size will not be correct and an actual serving size will need to be inserted.
- (O) Preparation. A description of how to prepare the recipe. This is only needed if one is creating recipes for others to use. It is not required for the calculation of nutrients.
- (O)Many other attributes could be collected for recipe documentation, such as remarks; a couple of hints lines; where the recipe is used; its main product, its product group, its type, its density, various dates such as date created, tested, analyzed, converted and preparation time.
This defines a single recipe which then becomes a single entry in the database.
First Nations Food, Nutrition and Environment Study

We are a multi-organization research team (University of Northern British Columbia, University of Ottawa, Université de Montréal, Assembly of First Nations and Health Canada) that has used CANDAT since 2008. So far, we have used CANDAT to enter over 5000 single and repeated recalls. The software is easy to learn and use. One of our students doing data entry mentioned that CANDAT was easier and more friendly to use than another program he had been using. We are able to incorporate traditional foods and recipes from our study easily into the database. The software developer is always open to suggestions from CANDAT users to facilitate data entry, such as viewing the food description when reviewing data entry and automatic repeat of past key word searches. Above all, the technical support provided by Godin London Incorporated (Gaetan) is always top-notch. He is prompt to answer questions and to solve problems. Recently, we requested a new feature which would enable users to view the food description when reviewing data entry and they were able to do this within a few days. Also, when validation of a dietary file with a more recent version of the Canadian Nutrient File was needed, they were able to write a program that allowed the file to be imported back into CANDAT (from SAS).

This was all done under the no-charge support provided with all CANDAT licences. I would highly recommend CANDAT to any nutrition researcher. Gaetan always strives to adapt CANDAT’s capabilities to suit its users.
Amy Ing, M.Sc.
Data Analyst
First Nations Food, Nutrition and Environment Study
www.fnfnes.ca
University of Guelph

I have used Candat for many years for the analysis of 24 hour recall data, and for the development and subsequent analysis of food frequency questionnaires for two different studies. The range of analytic options provided by Candat, and the fact that it is based on the latest version of the Canadian Nutrient File, are key features.
Assistance with the development of FFQs and translation of responses into the format that can be analyzed with Candat is available on an as needed and timely basis. Response is usually within 24 hours. And, there is no problem asking for help.
I have used Candat for years because of GLI’s knowledge and continuous efforts to make the software ever more powerful.

Susan Evers PhD
Professor
Department of Family Relations and Applied Nutrition
University of Guelph
Guelph, Ontario, N1G 2W1
McGill University

We use CANDAT because it is the best software giving access to the Canadian Nutrient File (CNF) that we have been able to find. It allows us to structure our data to provide the results that we need. For example, we have made consistent use of the food grouping capability that provides us with nutrients from these food groups so we can write manuscripts pertaining not only to the nutrients but also the food sources in the Canadian population. Support from the software provider is exceptional and very responsive to user needs. For example, when Health Canada removed some units from the Canadian nutrient file that were essential to the data entry, Godin London Incorporated extracted these from an older version of the CNF and added these back to CANDAT. Godin London Incorporated has also responded to our needs by adding functions that save us time when doing corrections and data cleaning.

Louise Johnson-Down
Survey Coordinator Food habits of Canadians
McGill University 21,111 Lakeshore
Ste Anne de Bellevue QC
H9X 3V9
Tel:514-398-7808
Fax: 514-398-7739
View food and meal descriptions by pressing “F1” over the code

When reviewing data input it is now possible to see the descriptions of the food and the meal codes that have been entered. Pressing the “F1” key at the top left of the keyboard will show the description for about 2 seconds. If that is too long for you simply press another key. A quick way to go through all your input for foods is to simply go to the first food code, press F1, glance at the result and then press the arrow down key to go to the next food. You will need to press the arrow down key twice (if you are fast), once to remove the description of the active food and once to go to the next food. Pressing “F1” again shows you that food’s description. It can become a quick two finger action, very efficient.

The time the description is shown can vary. You can set a longer time using the system message utility. Again, pressing any key will remove the description and allow you to proceed.

The F1 key has also been implemented for the quantity field. Pressing F1 while in that field will show the food quantity in grams and its energy value based on the quantity and unit codes entered.