How to differentiate US "Total carbohydrates" that include fiber from Europe "Carbohydrates" that exclude fiber

[stephanegigandet]

What

In the US and Canada, the "Total Carbohydrates" value include fiber. In Europe, the "Carbohydrates" value excludes fiber.

We currently have only one field for carbohydrates, where we put what is written on the package, but we don't record if it includes fiber or not.

Proposed solution

One solution could be to have 2 different fields "Total carbohydrates (including fiber)" and "Carbohydrates (excluding fiber)". One drawback is that it would complexify apps and it is likely that some people will put one value in place of the other.

Another solution could be to be able to set a field "Carbohydrates include fiber". This field could be populated from product photos, or set automatically for US imports and products added in the US and Canada. But there's also potential for errors, especially for products that could be sold in multiple countries.

Additional context

A good thing is that the carbohydrates value is not used in the formula for scores like the Nutri-Score or the UK food trafic lights, so this problem does not affect them.

Part of

• 🇺🇸 Improve support for the United States (tracker) #5689

[github-actions]

This issue is stale because it has been open 90 days with no activity.

[CoryADavis]

I'm currently working on implementing an Open Food Facts contribution system for my app which serves primarily users in the US and Canada.

I really like the first proposal! I think it would be quite comfortable if this were able to work similarly to how salt and sodium are currently handled. Modifying the next USDA Branded Database import to use the proposed total carbohydrates field would likely clean up a lot of existing entries, and maybe in the future robotoff could help prevent and fix errors by using a label type classifier. Label type would be a pretty cool new field too, because it allows for the digital recreation of the food label.

EuroFIR has a lot of experience making food data sourced from different nations work together, and they take the following approach:

Carbohydrate, Total [CHOT]
This field is for all indigestible and digestible carbohydrate. This is the same as US and Canada label standards for Carbohydrate.

Carbohydrate [CHO]
This field is shorthand for "Carbohydrate, Available", and is for only Carbohydrate digested and absorbed in the intestine. This is the same as European label standards for Carbohydrate.

Fibre, Total Dietary [FIBT]
This is the field they use for fiber, which has no substantial differences across label standards.

When only CHOT is provided, they calculate CHO by difference, CHOT - FIBT.

When only CHO is provided, they calculate CHOT by summation, CHO + FIBT.

[Dieterbe]

I'm not super familiar with OFF, but if we can't differentiate between total carbs (including fiber) and net carbs (excluding fiber), that seems like a huge problem, and renders stats for many fiberous ingredients very unreliable.
Fixing this would be highly appreciated, all the suggested solutions only differ in minor implementation details and seem generally fine to me. Whichever one allows this to be fixed soon. Though, the EuroFIR approach seems a bit redundant to have 3 fields when you can compute any 3rd from the other two.

[CoryADavis]

Having both total carbohydrate and carbohydrate is just about offering a convenient API. Developers with varying write and/or read use cases serving different region requirements will naturally prefer one over the other.

[teolemon]

• @Dieterbe @CoryADavis Can you add 👍 to the issue so that our issue ranker identifies it as a top issue.
• I've bumped it to P1.
• Having a geo-fenced display to country which display it like this sounds like a good option.
• Wording is going to be complicated anyway (see the sample above which doesn't include "Total"
• In edge cases (people travelling) i'd almost be tempted to add a tutorial so that the user doesn't make mistakes. "Does the nutrition table look like that" ? But it's not going to work for the API.
• A more complicated solution would be to add On the fly quality checks issues #8420 to ensure the user makes no mistakes

[CoryADavis]

Yes, for our users my plan would be to display and assume one label type based on initial geo-data or country selection, and if the data doesn't add up using the respective carbohydrate assumptions we'd reject the submission.

If we had redundant fields or the includes fiber toggle in-app, I think users would definitely get confused.

[Dieterbe]

@CoryADavis I like that approach, although I suspect for many items it's hard to automatically detect whether the data adds up, because (I think) many items will have more carbs than fibers anyway (so you can't tell if they're included or excluded just from the data). I think therefore we need to ask users to confirm our detected location and give them a prefilled checkbox / drop-down showing US/CA vs EU (or "other".. not sure how it's done elsewhere)

[CoryADavis]

💯! For us that takes shape in the form of a label type selector to change preference from the pre-selected default, but for OpenFoodFacts, probably a check box/drop-down.