Three papers relating to the review of the Eurocode 2 food coding system were circulated prior to the workshop. They were entitled:

Ian Unwin (Cambridge, UK) introduced the proposals of the report on the Eurocode 2 Review and modified Core Classification which is now available from the Danish Veterinary and Food Administration. He described the existing Eurocode 2 system, using examples which also illustrate some of the problems noted in the report; these are reported in Annex 1 to these minutes. As well as the hierarchical coding system, it is important to consider the further aspects of the overall objectives and policies of Eurocode, involving the descriptor system, recipe information management, the documentation, and the potential for effective software support of coding. An integrated approach is needed for the policies and documentation of these various components of the system. Documentation of the Eurocode 2 food coding system exists only as a draft manual which form good basic structure of explanations and examples but unfortunately contains many cases of lack of clarity, inconsistencies and errors, for example in when and how the descriptor system should be used.

Use of the Eurocode system would be helped by clearer statements of policy on the principles to be applied in coding, for example when classification should be on biological source and when by product type, and in assigning terms from the descriptor system. The report presents a modified Core Classification for categories at the intermediate subgroup level as the basis for further improvements to the coding system. The proposals applied two specific constraints which could be removed in further revisions, namely that categories were still assigned within the shallow, three-level hierarchy and that foods were not switched from one to another main group. The Core Classification retains existing codes by specifying that coding support computer systems should allow coders to assign terms rather than the storage codes themselves and should incorporate facilities for maintaining a separate logical ordering of the classification hierarchy. Discussion and further revisions, possibly involving additional levels in the hierarchy, are required to finalise the Core Classification before the modifications are extended to the food item level. The discussions should also include a further review of the requirements of coding with regard to recording consumption data, to aggregating that data and to matching with food composition data.

Nadia Slimani (Lyon, France) presented the requirements that an international epidemiological study has for a food coding system. It should be complete and exhaustive, covering the wide diversity of foods reported, avoiding concentration on specific criteria such as fat content, and recording a maximum of information for later analysis of dietary data. It must be flexible, with a conceptual structure allowing the addition of new foods or other food descriptors. A multifactorial approach, possibly incorporating a semi-hierarchical structure, may be a more appropriate alternative to a fully hierarchical system. It should be consistent and systematic, with consistent classification rules within and between (sub-)groups based on unambiguous and reproducible criteria and a uniform approach to the recording of unknown, irrelevant and imprecise reports. The concept of a single food classification is now obsolete as a food system must allow foods and recipes to be classified according to several independent criteria or combinations of criteria. Computer support is required for easy retrieval by a food's preferred name, brand name or alternative names, its food group or its descriptors, and for sorting and analysis. Identification codes should be specific to a food item and highly discriminating between foods, and independent of food group codes to allow re-classification according to alternative criteria. Documentation including user's manual, thesaurus, food index and specific examples should be well-designed and maintained in a way that allows updates to be easily circulated to users.

The system developed for the EPIC project is an ad hoc coding system based on the Langual principle of facets, adapted to the need for the international collection of consumption information as reported by study subjects. It meets many of these requirements but this system, which restricts the number and type of facets and descriptors to those which the subject could report (e.g. cooking method, preservation method, etc.), does not contain all the facets of the original multi-factorial Langual system or those of further possible etiological interest (e.g. packaging, additive or contaminant content, etc.). Thus the basic structure of systems designed for coding food consumption internationally should include, in a systematic and consistent way, the maximum range of detail (as distinct facets) to leave more flexibility in the further use and analysis of dietary data, whatever the field of application. The lack of flexibility of Eurocode suggests that there is a basic structural problem with the hierarchical approach. Maintaining the existing codes, as proposed in the 'Decisions' workshop paper, may be an obstacle to the substantial improvements needed by the system and is only necessary if Eurocode is already widely used. The proposal that future modifications to Eurocode can assume that coders will use classification categories rather than its codes, allowing more complex codes to be used for storage, is acceptable. The proposal to allow additional hierarchical levels should be used with care, avoiding the introduction of very specific levels. The use of a hierarchical classification internationally may lose specificity but this is counterbalanced by the more widespread use of a common system.

Ilda Martins (Lisbon, Portugal) discussed various aspects relating to the coding of recipe information. When comparing food consumption for different countries, it is not sufficient to record dishes as their Eurocode 2 codes alone because the recipes are often completely different even when the same name is used. In Eurocode 2 a mixed food can be linked to information on the ingredients and preparation method through the last field of the code. The information is held in national recipe files although as yet this framework has not been established. Even a simple recipe such as 'Scrambled egg' shows significant variations between national food tables and commonly used generic names such as 'Beef stew' may be used for dishes which vary enormously, for example in their relative amounts of meat and vegetables. The 'Beef stew' example shows a further problem with recording recipe ingredients using their Eurocode as the existing codes do not cover all possible cuts of meat and any removal of separable fat will also affect the composition. Information recorded for recipes should report their full disintegration back to basic ingredients through several steps if necessary, for example from a cheeseburger back through the hamburger bun to flour, sugar, etc. An important aspect of this is the inclusion of cooking yield for the recipe. Thus proposals for the coding of recipe dishes must allow for their detailed and accurate reporting rather than relying on a simple code based on the dish name. With regard to the Fish group of the Core Classification, the Perciformes subgroup includes examples of scaly and non-scaly species, and fatty and non-fatty fish. Both these criteria are useful classifiers of fish.

Edelgard Hermann-Kunz (Berlin, Germany) was unable to attend the workshop but submitted her comments on the report which were read to the meeting by Ian Unwin and are reproduced as Annex 2 to these minutes.

Attempts to assign Eurocode codes to food records in the German Food Composition Table (BLS) provided many problems arising because codes were not specific enough, necessary generic food items were missing, or the available descriptors were not clear enough. A particular problem is recording the relationship between weights and description when a food is weighed raw and consumed cooked. The BLS classification is used for coding all consumption survey records so that these can be matched with the composition data. It provides 7 levels, with 4 levels for identifying the food and with additional information on, for example, the weight consumed.

Consistent coding of mixed foods and the management of recipe information between countries would help with international comparisons of consumption data, but coding a dish according to 'its specific cultural identity' may improve comparibility within a country. It may be difficult to get a group to undertake the central support for code assignment and recipe file management. However use of recipe files will improve the comparibility of data, allowing Eurocode recipe codes to be assigned at the national level. But the use of international recipes where appropriate should be investigated further. It is agreed that improvements are required for coding ingredients in a state different from their consumed state and for recording variations in recipes, possibly using descriptors and modifiers of the basic codes.

Some specific comments on the review of the main food groups were made (see Annex 2). The 'Use context' aspect should be added to the descriptor system, with the "for dietetic use" subgroups being replaced by the descriptor term 'Dietetic use'. Descriptor terms for the state of foods when weighed are required for recording more information on consumption as reported.

Several main groups in the Eurocode 2 classification require extra hierarchical levels. It is also necessary to maintain the logical order of categories when new ones are inserted, preferably by leaving gaps between assigned codes. Although in an operational system codes should not be changed, maintaining the validity of already coded data, Eurocode is probably only in use for higher level aggregations of data. Thus at the current stage in developing the system, changes in codes are acceptable and a preferable approach to maintaining the logical order of categories to the proposal for a separate logical sort code. The retrieval, aggregation and sorting of data might be easier if users can directly use the stored codes instead of working with additional files. In conclusion, it is preferable to insert new codes (based mainly on the core classification) into the existing Eurocode classification even if this means changing existing codes. Once the system is in widespread use, updates should largely avoid code changes which should be possible if the design of the new system is flexible enough.

The use of Eurocode 2 in relation to the handling of household budget survey and food balance sheet data was discussed, with the use of 'Commodity trees' and collaboration with Eurostat on food balance sheets being suggested. Thus it was suggested that the Eurocode 2 system might move in the future towards being a classification of commodities rather than of foods 'as consumed' which is the current premise. Changes to commodity foods to their state 'as consumed' would be recorded through descriptor and recipe systems. It was intended that Eurocode should support household budget survey and may be used for the aggregation of data. A check should be made whether there is currently significant use in these areas and, if not, it was considered that codes can be changed in a revised Eurocode system.

Further work on the revisions to Eurocode 2 was discussed. It was suggested that this should concentrate on producing an improved classification, leaving development of the descriptor and recipe systems to separate discussions. It was agreed to produce a proposal on a final version of the Core Classification within 3 to 4 months. As well as taking account of feedback on the classification listing circulated prior to the workshop, this would expand and modify the present version using additional hierarchical levels, development of clear policies on categorisation which might involve moving items between main groups, and changing codes as necessary to produce a system that supports logical ordering and the insertion of new codes. The Core Classification will be documented with scope notes which will not only define its categories but also note how they might be further subdivided when the lower levels of the classification are defined and their requirements for additional information recorded through associated descriptor and recipe systems. Drafts of the documentation could be made available on the Internet for those actively reviewing the proposals but its availability should not be more widely publicised until a later stage in the work.

The classification consists of three main levels, with a further one for recording a recipe identifier for mixed dishes. These parts of the code are separated by a period (.). At the top level, the classification assigns foods to one of 13 main food groups. These are divided into sub-groups which can be further divided into a food item level (which in some cases may be lower level sub-groups, e.g. code 3.11.6, 'Meats; Meat products; Offals'). The Meat and Meat Products main group illustrates the problem of the shallow hierarchy, having a sub-group of Poultry with items such as Chicken leg. It is not possible to code the intermediate level of Chicken which is often required. In this main group, the subgroups are mostly defined on the basis of biological organism, e.g. 3.1 Beef, but Meat Products is a separate subgroup which is subdivided on the basis of product type.

The coding of 'Soya beans' and their products illustrates the problems which arise because some groups are categorised by biological origin and others by product type. This basic food item is coded as 7.1.8, within the Pulses subgroup of the Pulses, Seeds, etc. main group. Diverse products such as soya milk and textured vegetable protein are coded as 7X.1.8, i.e. as a mixed food (designated by the 'X') derived from soya beans. On the other hand, the Milk and Milk Products main group codes animal milks on product-based criteria and does not distinguish the originating species. However, its subgroup 1.8 Cheese substitutes may be used for coding soya-based products, and soya-based miscellaneous foods are given codes such as 12X.9.7 Soup, pea/bean base and 12X.10.1 Sauces, vegetable base. As a result of the mixed classification criteria, coded data does not record total consumption of soya products nor of milk-type products.

Some mixed foods have specific codes (for example 12X.9.7 and 12X.10.1 as above) and are referred to as generic mixed foods. In other cases an 'X' is added to the code for a basic food, e.g. 4.4.2 Cod is modified to 4X.4.2 to code a dish that has Cod as the main ingredient. The first rule for coding a dish is with a generic mixed food code if it exists. Failing that, the second rule is to code on the basis of 'cultural identity', e.g. Chilli con carne as a bean dish rather than a meat dish. Thereafter, rules based on the main ingredient are applied. Correct and consistent application of these rules is necessary as often they will determine the main group to which a dish is assigned. Eurocode 2 postulates that recipe management will be within a national framework. If a national code is associated with a recipe, it forms the final element of the assigned code, e.g. 6GB.2.14.3 refers to the third British recipe for Meat pie.

The Eurocode 2 descriptor system provides categories and associated codes for 5 different aspects (facets) of additional information to be recorded for coded foods. For example, the Thermal treatment at consumption facet has terms for Deep fried (code T7) and Dried (code T5). This illustrates a lack of clarity in the definition and documentation of this facet which mainly contains terms relating to cooking immediately prior to consumption. On the other hand, Dried is the result of earlier processing (which in some cases might not involve heat) and a state of the food which may not remain the case for it as consumed since, for example, its use includes Coffee and Soup. There are a number of cases where the documentation of Eurocode 2 suffers because of a lack of clear definition of policies and inconsistency in their application in particular circumstances and examples.

Submitted by Edelgard Hermann-Kunz (Berlin, Germany)

Some years ago, we tried to assign the food records including in the German Food Composition table (BLS) to the Eurocode codes. But many problems arose and the matching was impossible in a lot of cases, e.g. in meat, sausages and cakes, because the Eurocode codes are not specific enough or necessary generic food items are missing and the use of descriptors does not provide the necessary clarity. The classification of the BLS involves 7 different levels of details, the first three levels relate to hierarchically ordered food groups (main-, sub- and lower subgroup), the fourth level represents the single food and, for example, the final level refers to the weight of the amounts consumed. The BLS provides different possibilities to record the weight of the amounts of consumption independent from the state of consumption, e.g. it is possible to describe that a food is consumed cooked but the recorded weight is measured prior to cooking (specific factors for weight losses or gains during the processing of the foods are implemented in the BLS), also it is possible to describe a fruit eaten without peel but with the amounts of consumption (e.g. bananas) weighed with peel. The existing Eurocode does not provide adequate coding possibilities for the mentioned BLS codes; so it is not possible to describe clearly, for example, a food with two thermal treatment descriptors 'raw' and 'cooked', where one is related to the state in which the food was weighed and the other to the state of consumption.

Since the matching of consumption and composition data is required for calculations of nutrient intakes at individual level, all consumption survey data are coded with the BLS in our institute; the Eurocode has never been used for coding, but in a few cases for data aggregation since on group or subgroup levels the assignment of BLS codes to Eurocode codes is feasible.

I agree that the existing Eurocode is incomplete and not specific enough to serve as a basis for nutrient calculations and for the back-calculation of recipe information to the ingredients. Several improvements are needed, e.g. the descriptor system should be enhanced, the addition of extra generic names is necessary and to increase the number of hierarchical levels would be very useful. Including standard end-of-group codes like sub-groups for 'others' coded, e.g. as n.88 as mentioned in the review of main group 2, may be helpful in several groups. The limitations of the Eurocode derived from the preconceptions of 'foods that are nutritionally important in the European diet' should be reconsidered; because the assumed 'average European diet' can change and coding of foods important in ethnic diets are often not possible. But I see some problems in the creation of an ordering mechanism separate from the Eurocode 2 code, which is required to improve the Eurocode system and to maintain the classification system at the same time (notes to that, under 'classification hierachy and coding system').

The coding of mixed foods is a really difficult area; to operate this centrally to make coding consistent between countries would, of course, have advantages in international comparisons of consumption data. On the other hand, comparisons within a country could become more difficult, if dishes are not coded according to 'its specific cultural identity'. To manage the coding centrally means a lot of organisational work and to find a group willing to do that will not be easy. Practical problems can arise if coders have to wait long for an adequate code. It is difficult to know what would be an appropriate approach in this difficult area. But since the problems in comparisons will be less important, if mixed foods are, when possible, entered in the recipe file and if recipes can easily be broken down to the single food level it is preferable to manage the coding at a national level. But the idea of creating international recipes for mixed foods and dishes, which are traded internationally, is good and the possibility of including international recipes in addition to national recipe codes should be investigated further.

It is correct that, for the adequate description of recipe ingredients added in a state different from their consumed state, the enhancement of the Eurocode classification with ingredient-only food items would be useful.

I agree with the suggestion that it should not be necessary to predefine minor variants of a standard recipe. It seems to be a possible solution, that, for example the use of different milks can be handled with the help of descriptors and a system which modifies the respective basic codes. Also the idea of using the recipe system to hold information on aggregated 'foods', consisting of a set of individual items weighted according to their market share, is very good, but a lot of work is required to realize that.

I agree with the proposal to extend the descriptor system with "Use context" aspects and to replace the subgroups 'for dietetic use' with the descriptor term 'Dietetic use'. Additionally it would be helpful to have a descriptor term which refers to the state in which the foods were weighed. This would allow the coding of more information as it is reported.

I agree with your opinion, that there is a need "to increase the number of hierarchical levels" in several main groups of the Eurocode 2 classification. This means that for maintaining the logical order of the categories it will be necessary to insert new codes, but, as you mentioned in the review, the existing classification does not allow this as vacant codes are not included. And, although it is correct that it should be avoided to change the codes since otherwise the compatibility with already coded data will be lost, at the present stage of work I would not agree with your proposal that "existing codes should not be changed when the classification is updated". Probably the whole Eurocode in its existing form has not been used till now. As far as I know, the EPIC study, for example, is being coded with Langual or a system adapted from Langual. But in some smaller studies Eurocode is used to compare food intakes of the population of different countries; e.g. in the "Transfair study" the consumption data, already coded with the respective national food codes, were aggregated on food group levels (mostly the main group level) with the help of Eurocode. Since, I believe, that until now in most of the studies which use the Eurocode, this use is limited to the adoption of criteria for aggregations on a quite high group level, I do not expect many problems to arise if codes are changed. No information will be lost because detailed descriptions of the consumed foods are coded with national food codes and the changing of rather rough criteria for aggregation is probably not that much work. On the other hand, I see some problems in the proposal to separate the management of logical order from the codes. If I understand it right, then two different, independent systems of codes will exist. The current codes of the Eurocode would be codes for storage only, and therefore no logical and hierarchical order is necessary. But a second system of codes has to be developed for the management of a logical order. I think the advantage of keeping the existing codes constant is very small, but the existence of two different codes bear the risk of loosing clarity. And although, through the help of computer support for coding, it is not necessary for coders to work directly with codes, logical and hierarchical ordered codes are helpful in some areas and easier to handle for users than a new management system. For example, the codes are helpful to get a complete overview of the whole classification system, the different levels of classification are clearly recognizable. The assignment of the national composition databases to the consumption data is easier to do on the basis of hierarchically ordered codes, which are stored directly with the consumption data rather than on the basis of storage codes. The retrieval, aggregation and sorting of the data might be easier if user can directly use the stored codes instead of working with additional files. And even if the proposed separate management system provides easy ways of application, this system has to be altered, too, when new subgroups and items are needed to add. Also, the development of the new system will take a lot of time and until this system will work sufficiently the use of an improved Eurocode would not be possible.

For the mentioned reasons I would prefer to insert new codes (based mainly on the core classification) into the existing Eurocode, even if this means to change the codes. Of course, this should not be the normal way if the classification is needed to be updated again; in the future the change of codes can be largely avoided, if the design of the new system is flexible enough.