Archive | Recipes

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.

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.

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

menu main 4

this from the choices then presented:

menu recipes 400

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


are explained in Appendix A (click on the screen to see the explanation). 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.

call: +1 (877) 977-2664 (toll free)