Using QR Codes to Store Nutritional Information

Posted on Sunday, March 21, 2010

3 Replies

I recently signed up for an online website that tracks your daily calorie intake. The particular service that I signed up for (there are a lot of them out there) is FatSecret. It has a rather substantial database of nutritional information for a lot of foods, ranging from raw produce to food that you would order at a restaurant. The interface allows you to track both what you eat and how much you exercise. Most websites like this also have mobile applications that allow you to update your food diary from your iPhone, BlackBerry, or other smart phone. Today it dawned on me that QR codes can enhance the usability of sites like FatSecret.

A QR (Quick Response) code is a 2D bar code that can store a large amount of data as text. The beauty of a QR code is that the text that it contains can often be interpreted by software on modern smart phones. For example, if the QR code contains the URL of a web page, then the QR code software will display it in your phone’s browser. This is a growing trend in mobile marketing. QR codes are also printed on some food packaging to store data such as nutritional information.

So, utilizing QR codes to store nutritional information on food packaging has the potential to allow users of mobile apps like FatSecret to simply scan the code and upload the nutritional information directly to their account for tracking. Back in September of 2006, McDonald’s used QR codes on its food packaging to direct customers to the web, where they could view nutritional information about the food. My idea would take things a step further, and actually store the nutritional information in the QR code itself. Since QR codes can handle a rather large amount of character data, you could store the data as XML. Then, the software for your mobile app would be able to scan the QR code, interpret the XML data, and update your food diary with the appropriate nutritional facts.

I wouldn’t be surprised if we see something like this come to fruition in the near future. Although, requiring food manufacturers to adopt a standard XML schema for representing nutritional data may be a bit of a hurdle.

Danilo

Also thought about nutrition facts in qrcodes. The amount of data it can store is not that much (4296 characters), so XML may not be ideal because it’s too verbose. It would have to be a more compact format, or a link to a web resource with the information.
Carl

I agree that a compact format would desirable. Even if an XML format would “fit” in the available number of characters, the resulting QR image would be larger, uglier and more difficult to scan. JSON is one suggestion. Why not propose a format on your blog to take this one step further?
Max Osterhasi

This is not a new problem and was already addressed by the automotive industry &/or the Department of Defense. It is, of course, debatable, if the standards they came up with are useful for current end-user S/W applications, but at the least they exist. General Motors, for example, came up with a standard, where they separate various parts/pieces of data with special Group Separator symbols. Sometimes a Record Separator is used at the beginning of the first part of data, and again after the last part of data, followed by an End of Transmission . In case of GM, the , and are special hidden ASCII characters. They are not typed literally. When they are scanned into a general text screen (like Notepad) you will not see them. You will either see spaces or little squares (place holders) on the screen. The original purpose of these separator characters was for scanning into EDI (and similar) types of systems. These systems are programmed to look for the , and characters and effectively separate the pieces of data automatically when scanned into the systems. The DoD uses a different system what’s called a UID (Unique Identification) format, which I believe is based on the GS1 system, with different headers & prefixes to subdivide the data stream. Both systems deliver data strings, which are not very meaningful to a human reader, and require some S/W, which can interpret / decipher the data stream. On the other hand they require less characters than, for example, XML. You can Google all this, but it can be a rather dry subject.