Consumption Reporting

In the following chapters we describe the key data structures for reporting food consumption data.

Reporter

Aspects to be considered for the ReporterService:

Filtering - e.g. by respondent alias or by interview date say.
Nutritional attribute selection - provide choices of FoodComponent(s) given a FoodComponentCatalog.
Aggregation of nutrient values:
- MEAL - Sum total of nutrient values for each meal.
- INTERVIEW - Sum total of nutrient values for each interview.
- RESPONDENT_AVERAGE - Average of nutrient values for each respondent per interview (averaged over all interviews available for a given respondent).
- RESPONDENT_AVERAGE_GROUP_BY_FOOD_GROUP - variant that groups by food-group.
- RESPONDENT_AVERAGE_GROUP_BY_FOOD_GROUP_AND_SUBGROUP - variant that groups by food-group and food-subgroup.
Aggregation of Composites - allow for some composites to be reported as single consumption (instead of splitting them up into their sub-records, which is the default).
Language - Translation e.g. in which to express column headers.
Target FileFormat (at least support EXCEL).

Requirements:

Connection to a Food Composition Database (FCDB)

ReportOptions are either provided in a static way (configuration) or originate from a data base.

Figure 1. Reporter

Interview Set

An Interview Set is a set of respondents including their interview and consumption data.

Figure 2. Interview Set

Perhaps a good design for calling clients is to store the reporter’s Clob results in a BlobStore.

Consumption Record

A record is either

directly a consumption entry (Food, FryingFat, Product)
or a Composite of these
or a Comment
or an informal entry (TypeOfFatUsed, TypeOfMilkOrLiquidUsed) attached to another record (Food)

FryingFat is fat used during cooking, which is also added as consumption record (amount reducing factors considered).

A Record can have arbitrary Annotation(s) such as group information or notes.

Figure 3. Record Model

Consumption Correction/Amendment (Draft)

Typically with surveys, some issues with e.g. recipes are discovered only after interviews were made. It is likely that consumption data will need some correction as post processing step.

Consumption Identification

Consumption entries have no identifier per-se, so we need to address specific entries that need corrections using 2 steps:

Given a respondent alias and a consumption date, a specific interview file can be identified.
Given a specific interview file we can locate a contained consumption record using its ordinal within the interview.

On creation of such a ConsumptionFileAddress we should also track the interview file version using a hash (e.g. SHA256), such that we can protect against upstream changes of the file in question.

Corrections are either adding a new consumption entry or deleting an existing consumption entry or changing the amount of an existing consumption entry.

Figure 4. Consumption Correction