Nutritional analysis: software specification

Essential Criteria of the software

This software specification is specifically for the use of Scottish Local Authorities, or their contracted caterers, to procure software which will be used to plan and nutritionally analyse food and drink provision in schools in order to meet the Nutritional Requirements for food and drink in schools (Scotland) Regulations, 2020.

Food and Nutrition Data

1. The software is required to be an online system allowing users to undertake:

• recipe analysis
• daily nutritional analysis; and
• weekly nutritional analysis (4 days or more, but number of days can be specified by the user)

2. The nutritional analysis software (hereafter termed "the software") must contain a food directory consisting of data on:

• Food and drinks, including manufactured products
• Recipes

The food directory should be organised by food groups. The foods, drinks and recipes will be used to plan weekly menus and undertake nutritional analysis.

3. The software must use data from the most up-to-date version of McCance & Widdowson's Composition of Foods Integrated Dataset^[1] (CoFID), which holds the composition of all basic foods.

4. The software supplier must ensure that a system is in place to update the database within 90 days of new data from CoFID being published. The supplier must notify the user in advance of any update to ensure account is taken of new data in their menus and subsequent nutritional analysis.

5. For each food, drink, and recipe in the food directory, the software must hold data on the energy and nutrient content per 100g/ml. The data must include:

• Energy (kcal)
• Protein (g)
• Total fat (g)
• Saturated fat (g)
• Total carbohydrate (g)
• Total sugar (g)
• Free sugar (g) – see point 6 for further detail
• AOAC fibre (g) – see point 7 for further detail
• Iron (mg)
• Calcium (mg)
• Vitamin A (retinol equivalent) (microgram)
• Vitamin C (mg)
• Folate (microgram)
• Zinc mg
• Sodium (mg)
• Salt equivalents (g) – see point 8 for further detail

6. In 2015, the recommendation for sugar changed significantly and a definition of free sugars replaced non-milk extrinsic sugars (NMES). Free sugars are defined as all monosaccharides and disaccharides added to foods by the manufacturer, cook, or consumer, plus sugars naturally present in honey, syrups and unsweetened fruit juices. The sugars naturally present in milk and milk products (lactose) and the sugars in the cellular structure of foods were excluded. At present, CoFID does not hold data on free sugars. Therefore, the values for free sugars in data held within the software must be calculated using the following classification:

Free sugar	Non-free sugar
All sugars in fruit juice as well as table sugar, honey, sucrose, glucose and glucose syrups and added lactose or galactose added to foods (including whey powder)	All sugars in fresh, frozen, dried, canned or stewed fruit and vegetables.
All sugars in drinks including sugars naturally present in fruit and vegetable juices, smoothies and in milk substitutes	Lactose naturally present in milk and milk products
All sugar in fruit and vegetable purees and pastes, including jam and preserves, and products made from extruded fruit or veg

They key differences between free sugar and non-milk extrinsic sugar (NMES) are:

• Canned, stewed and dried fruit are not classed as free sugars (previously 50% of the sugar from these foods was classed as NMES and the other 50% as intrinsic sugar).
• Lactose and/or galactose (including lactose in whey powder) added as an ingredient and not naturally present in milk or dairy products is also be classed as free sugar. This was not considered as part of NMES.

7. Free sugar data calculated using the approach as described by Amoutzopoulos et al^[2] is available for food and drinks in the National Diet and Nutrition Survey nutrient databank. This is available to commercial companies on request from the UK databank archive (www.data-archive.ac.uk). This data may be of use to cross check or to guide estimated data where this is not available elsewhere. This should be used with caution and the following aspects noted:

• The databank contains several thousand food and drink products which are not in a logical order.
• The databank may contain several products that are very similar to each other, but not adjacent to each other in the spreadsheet.

8. It should be assumed that nutrition data from manufactured products provides fibre values using AOAC methodology. If however, the NSP value is provided, the following approach must be adopted in order to estimate a reasonable AOAC fibre value:

• fibre values given as NSP should be multiplied by 1.33 to give the AOAC fibre value.

Where this calculation has taken place, the software must have the function to flag up these fibre values as estimated values in the nutrient analysis report.

9. As some food labels contain salt and others contain sodium, it is necessary to include both values to ensure the user does not confuse these two values, particularly as they are often listed using different units (mg vs g). To convert mg of sodium to g of salt equivalents, you need to multiply the mg sodium amount by 2.5 and divide by 1000.

Sodium to Salt
200mg of sodium x 2.5 = 500mg of salt

500mg / 1000 = 0.5g of salt

10. To convert g of salt equivalents to mg of sodium, you need to multiply by 1000 then divide by 2.5.

Salt to Sodium
0.5g of salt x 1000 = 500mg of salt

500mg / 2.5 = 200mg of sodium

11. For each food, drink or recipe in the food directory, the software must hold data on:

• The ingredients
• Item name and/or code
• Quantity of each ingredient used (g/ml)
• Cooking method
• Total weight of all ingredients
• Total weight of finished dish
• Number of portions/servings from the recipe/product
• Suggested portion size (g/ml)
• Nutritional values of the nutrients listed in section 5 per 100g and per portion

12. A tracing/tagging facility should be in place to identify which source of data has been used for a food, drink or recipe to identify whether this has come from the manufacturer, CoFID (including date of update), or is estimated data entered by the user. The data coming from CoFID should not be able to be edited by the user.

13. If, for any reason, data for any nutrient listed above is not available for a particular food or drink, the software must have the ability to flag these up as missing values in the nutritional analysis report, and to distinguish this from a zero nutrient content in the database.

14. For cooked recipes or products, the software must provide the facility to estimate weight changes and nutrient losses as a result of cooking if this is not measured directly. Values in appendix 4.3 of 7th edition of 'McCance & Widdowson's Composition of Foods^[3]' must be applied.

15. The software must provide the facility to add new food and drink products and recipes not included in the CoFID data. This data would include:

• Product or recipe name
• Manufacturer (if applicable)
• Nutrient data of the food per 100g as listed above, and indicate whether the data is 'as purchased' or 'as served'.
• Details (name, contact details and date) about the user who added the product and accompanying data to the software

16. If there are missing nutrient values for the products or recipe, these should be sought from the manufacturer (where applicable), or substituted with the nutrient value of the most similar food source from CoFID. The source of the value used to fill in the missing nutrient must be able to be traced/tagged, along with the user who has entered the value. These estimated values must be clearly identified as part of the output of the nutrient analysis report.