Tracking your micros from food [Part 3] - Is your data accurate? [n = 1 experiment #2/2019]

Updated: Oct 1, 2019

Have you noticed that the nutrient composition of the same food can be a little different across different data sets? Unless you happen to have a lab that you can use to analyse the nutrients in that steak or potato on your plate, most of us rely on the data sets available to assess our nutrition. This raises an interesting question. If you're tracking your micros from foods, can your results change depending on the data set that you use? Yes, they can. But more often than not, the differences are probably due to errors that you make while entering your data.

I decided to investigate. The NCCDB and USDA are both excellent sources for micronutrient profiles. If these data sets are both reliable, then you should see similar nutrient profiles for equivalent food entries, right? To check this, I entered the same foods and quantities for an entire day of eating into both databases. I'm no stranger to food tracking, so I'm able to carefully compare and select equivalent entries across both databases, or at least as similar as possible. I used different online tools to access the data sets - Cronometer (for NCCDB) and (for USDA). I compared the data to see if it matched.  Did the data sets generate different information about my macros and micros? At first, yes. I looked at the macro and micro totals for the day, not for each food. And each database painted a different picture of my sample day of eating. Of the 25 vitamins and minerals tracked, I immediately spotted some noticeable differences.

  • 10 micros had quite similar values.

  • Six micro varied by 10 to 20 per cent.

  • Nine micros varied by more than 20 per cent across the databases!

That's a lot of variation. And it completely changed my RDI analysis. For some micros, I seemed to have a deficiency if I looked at one data set, but not the other. Something seemed off. You know that old saying, 'If something seems wrong, it probably is?' I back tracked and looked at my data entries again. This time, I looked at the food entries that contributed to my micro values. One by one, I spotted the small mistakes I'd made - easy mistake to make - that subtly changed the nutrient composition of the foods selected.

Here's the five mistakes I made tracking micros from food (so that you don't have to make the same mistakes!) 1. How did you prepare it? Let's say you eat spinach lightly pan fried in some butter. You estimate that on your plate there's about 1/2 cup of spinach. That's its cooked portion. It's fairly obvious that the volume of food you eat affects the amount of micros you consume from that food. But it's easy to choose the incorrect entry in an app if you're quickly plugging in data, and this can affect your results. For example, I accidentally chose 'Spinach, 1 cup, Cooked from fresh' on Cronometer, and 'Spinach, 1 cup, Raw' on NutritionData. The vitamin E content of the 1 cup cooked is 3.7 mg, compared to just 0.6 mg in 1 cup uncooked. Doesn't seem like much, does it? But if the RDI is only 15 mg, then these little differences add up. Based on little selection errors like this, my final tally for vitamin E came in at 15.2 mg on Cronometer and 10.9 mg on NutritionData. If I'd just used NutritionData and hadn't picked up my mistakes, I'd have interpreted that I had a vitamin E deficiency. Different databases use different terms. The NCCDB contains an option for 'Cooked from fresh', but USDA tends to categorise plants as either 'Raw' or 'Boiled, Drained.' Because I didn't boil my spinach, I selected the other option. I should have adjusted my portion size to factor in the change in volume after cooking. For example, 1 cup of cooked spinach contains about the same amount of vitamin E as 4 cups of uncooked spinach. Same food, same amount, different preparation. [Side note: cooking can alter certain vitamins and minerals - for example, foods that contain vitamin C lose a quarter of their vitamin C after cooking. This is another aspect to consider that I didn't delve into here.] Take away message # 1 - Choose your entries carefully. Don't just look at the portion size (ie, 1 cup). Check how it's prepared - is the entry for 1 cup cooked or 1 cup raw? 2. Some of the data entries for the same foods did contain slightly different values for certain micros. In some cases, similar foods did actually generate different nutrient data. For example, the NCCDB and USDA told me different things about the retinol in beef liver. I adjusted my entries to try to make the separate data entries as equivalent as possible - I first used an equal portion of 100 g (9428 mcg v. 4874 mcg), and then I changed the portions so that each database lists the same amount of protein 9428 mcg v. 6579 mcg). I couldn't see an obvious reason for the variation. It didn't matter so much here, because beef liver puts you so far ahead of the RDI for retinol that it doesn't change your nutrient status.   Take away message # 2 - There can be differences here and there. This is likely to happen for some entries because different databases use different methods to calculate the micros. Keep this in mind if you only just meet the RDI because it may be that you're a little more deficient than it looks on paper. 3. Missing nutrients. Some food entries don't contain any details of certain vitamins or minerals. Just because a food entry doesn't supply a value for a particular nutrient, it doesn't mean that the nutrient is not present in that food! It means that the scientists compiling the entry didn't have final data for the missing nutrient in that food. This matters because missing nutrient values for foods are ultimately calculated as zeros in nutrient intake estimates. Even the big databases have missing nutrients. For example, the NCCDB entry for 'Kale, Cooked from fresh' listed 1062 mcg of vitamin K, but the USDA entry for kale didn't include vitamin K at all. This made a big difference to my total daily vitamin K intake and put me far under the RDI. Like for vitamin E, I seemed to have a deficiency if I looked at one data set, but not the other. To correct this using the USDA entry, you'd have to crunch the numbers manually. Take away message # 3 - Check that the food entry contains the nutrients that you need. Look for entries that contain 50 + nutrients. Then double check to see if it's missing nutrients of interest to you (for example, common missing micros include iodine and molybdenum). For the missing micros, you'll need to do additional research on your foods to figure out if you're meeting the RDI. 4. Your choice of salt can affect your data on sodium.

Salt is salt, right? Not necessarily. The general rule is that 1 g of salt contains about 400 mg of sodium. Ie, 1 g of salt is about 40 per cent sodium.

But do you use salt flakes or grinder salt? Salt flakes are lighter and bigger than grinder salt. Because the salt crystals are bigger in size, you consume a smaller number of salt crystals at one time, even though you're still using the same amount of salt that you usually do - a pinch, 1/4 tsp, etc. As a result, it tastes less 'salty' than if you'd used the same metric quantity of a finer salt. You'll also consume LESS sodium than if you'd used the same metric quantity of a finer salt.

Does this matter? Yes! If you don't eat processed foods and you rely on adding salt to all of your meals as your main source of sodium, your choice of salt can change your sodium status. And if you don't get enough sodium, or your sodium status fluctuates dramatically, this can affect your hydration, fluid retention, performance, stamina, endurance and recovery.

A tsp of salt flakes is about 2 g of salt. 

A tsp of finely ground salt is about 6 g of salt. 

That means that per teaspoon, salt flakes supply about 800 mg of sodium, far less than a tsp of fine salt that contains about 2400 mg of sodium. So, if you add a pinch of salt to all your meals but it's salt flakes, then you'll consume less total sodium than if you'd used a finer salt that is more compact.

To make sure that I don't under shoot my sodium, I use a combination of salt flakes (I'll add this to my plate to finish) and either a pink salt or an iodised rock salt in a grinder (used to season as I cook) on my foods. Either is fine, but select your foods and adjust your portions to make sure that you have enough sodium in your diet. Take away message # 4 - Think about the kind of salt that you use to accurate track sodium from salt. Is it big, light salt flakes, or small, compact rock salt? Either is fine, but select your food entries (and adjust your portions) to make sure that you have enough sodium in your diet.

5. Missing foods. An odd thing I noticed is that the USDA does not seem to have an entry for full fat Greek yoghurt. Maybe it's a sad sign that many people are still clinging to a reduced fat mentality ...  Take away message # 5 - If you can't find the right entry for your food, choose the closest to it to minimise the differences in macro and micro values. Putting this into practice - Build in a buffer zone Is this a perfect experiment? Of course not. It's an n = 1 analysis using my personal data and some trial and error. But it's useful because it tests a practical scenario. To assess your micros, the obvious thing to do is to use a reliable database to generate your daily total of each nutrient and rate it based on the RDA. You can use this tool to identify deficiencies. So it's important to think about the way that you use this technology because it's easy to make a selection that can put your numbers out. It's also useful to realise that different data sets sometimes do tell you different things. It's impossible to confirm that generic data accurately captures the nutrients in the precise food that you're about to eat. But it's a useful tool if you use it carefully. Avoid making the mistakes I made, and you'll generate valuable data. To control for things that you can't control, the easiest method is to build in a buffer zone. You probably don't analyse your micros all that often (see Part 2 of this blog series for my explanation of a micros 'audit'), so it's sensible to factor in a margin for error so that you can see the bigger picture.