Get ahead with TrackVision updates
Join our newsletter today and don't miss out on the opportunity to be part of a community driving innovation in tracking technology.
Sign up now and be in the know!
Section 204(d) of the Food Safety Modernization Act in the United States - entitled “Additional Recordkeeping Requirements for High Risk Foods” - will not only require businesses to store records, but also send a subset of this data to downstream business partners.
In this article, you will learn:
FSMA 204 will require businesses in the USA to store and exchange lot-level traceability information if they produce, handle or process any food identified on the FDA’s Food Traceability List. The FDA has defined a series of Critical Tracking Events (CTEs), each containing Key Data Elements (KDEs), which they expect businesses to record. The FDA diagram below illustrates the CTEs and KDEs involved for a produce supply chain:
This presentation is a good summary of the Key Data Elements required to be recorded in each Critical Tracking Event. For example, here are the requirements for Receiving events:
One interesting point highlighted above is that you must also record the production origin of each batch/lot of food you receive - called the “traceability lot code source”. The ultimate source of the goods may be different from the entity you bought them from. Consider this example from the Retailer’s perspective:
The retailer buys salads from Distributor 2. But they are reliant on the Manufacturer sending data about the salad lot source location first to Distributor 1, and then Distributor 1 sending the same “traceability lot code source” data to Distributor 2, and then finally they need Distributor 2 to send them the information in turn for them to comply with the requirements of recording a “receiving” event. This example illustrates how important data sharing is in FSMA 204.
In summary, there are three main Critical Tracking Events (CTEs) where businesses must not only record data, but also send data to downstream business partners:
Let’s look at each in turn.
If you are a grower that harvests produce subject to the rule, you must send almost all Harvesting KDEs to the initial packer who will pack the “raw agricultural commodities” into customer facing packaging for transport. You must also provide basic business contact details. Here is the screenshot from the FDA guidance for harvesting, with the data sharing requirements highlighted:
Why is this necessary? This is because the Initial Packer also needs to record certain KDEs that come from the harvest step. Here is the corresponding FDA guidance for Initial Packing:
As we can see, certain KDEs for Initial Packing are actually related to Harvesting, including:
Therefore, for the Initial Packer to comply with FSMA 204, the grower must send this information to them. Here is a simple illustration of what needs to happen:
So in summary, in order for “Lettuce World” to properly record an “Initial Packing” event that includes Harvesting KDEs, they must get the Harvesting KDEs from Burwood Lettuce first.
In FSMA 204, the FDA also requires information to be recorded when a raw agricultural commodity (RAC) is cooled before initial packing. Similarly to harvesting, the initial Packer also needs information about the cooling step from the business that does the cooling. Here is the FDA’s guidance for cooling, with the data sharing requirements highlighted:
From the Initial Packer’s point of view, we can see they also need to record when and where the food was cooled (if applicable):
Therefore there is a data sharing requirement where the business performing cooling shares data with the business performing packing. To summarise with an example, a more complex Harvesting / Cooling / Packing flow where each step is performed by a different business might look like this:
Burwood Lettuce shares their Harvesting KDEs with Burwood Produce (the cooler), who uses some of those KDEs when recording their Cooling event. Burwood Produce (the cooler) shares their Cooling KDEs with Lettuce World, who records an “Initial Packing” event that contains harvesting and cooling data from both prior businesses.
The final scenario where data needs to be sent to downstream business partners is when food is shipped to another entity, which may happen many times in the distribution process for the food. If we look at the FDA’s guidance, we see that they advise that the entire Shipping event (all KDEs) should be sent to the receiver of the food.
This is necessary because the receiver of the food needs to record certain KDEs that only the shipper will be able to tell them. Here is the corresponding FDA guidance for Receiving:
As we can see, the Receiver is relying on information from the shipper so they can record:
As a final example, consider the following complex supply chain, where a manufacturer creates Packed Salads and ships to Distributor 1, who ships to Distributor 2, who ships to a Retailer:
The “Traceability Lot Code Source” is the manufacturing location of the packed salads - in this example, privately recorded in a “Transformation” event by the Manufacturer. When the manufacturer sells to Distributor 1, they will construct a Shipping event, which includes the source of the traceability lot (“TLC Source”), as well as “ship from” KDEs. This information will be included when Distributor 1 records their “Receiving” event.
The process then continues as the product moves through the supply chain:
Notice how certain information from the original manufacturer (namely, the Traceability Lot Code Source location) is pushed or “propagated” through the supply chain via this process.
Here are four ways you can share data with business partners:
Did you know there is an open data standard specifically designed to record and share “supply chain events” like those mandated in FSMA 204? It is called the Electronic Product Code Information (EPCIS) standard, and it is published and maintained by the non-profit GS1 standards organization. The best thing about this standard is that it can comfortably represent all the CTEs required for the legislation, including Harvesting, Cooling, Packing, Transforming, Shipping and Receiving. It also provides a set of standard APIs, based on the same modern technologies that power the rest of the internet (that developers love using), that let supply chain events be exchanged seamlessly without having to spend money on expensive integration projects. If two business partners have EPCIS capable systems, such as TrackVision AI, they can set up data feeds at a click of a button:
EPCIS is great because it provides you with a best practice standard to record and share all the CTEs required by FSMA. Unlike EDI, it is not limited to just shipping. The only challenge is that it is relatively new (especially version 2.0 - the latest version of the standard) and therefore it is still finding adoption in the market as a standard. If you are interested in utilizing EPCIS, TrackVision AI provides a fully featured FSMA solution that includes an EPCIS repository and APIs as well as extensive integration functionality that will automatically convert your data into EPCIS compliant format.
The second best way to share FSMA 204 shipping data is using traditional X12 EDI 856 Advance Ship Notice (ASN). An ASN is an electronic version of a “business document” that describes a physical shipment - who it's from, who it's going to, and what the contents of the shipment are. In FSMA context, an ASN would usually be sent that describes the pallets along with the batches of products within. This older data exchange standard is already widely used in retail, and there are many EDI providers out there. TrackVision AI’s FSMA solution also includes EDI data exchange capability, so you can choose whether to communicate via EPCIS or EDI.
The downsides of EDI include the fact that it is based on older technology which is more difficult for developers to work with and maintain, compared to EPCIS. Also, unlike EPCIS, it does not support the other CTEs required by the legislation, nor their data exchange requirements (for example, harvesting or cooling), so for these early stages in the supply chain, participants will need to find another way of exchanging data. Finally, although the ASN always conveys the “immediate previous location” where a shipment came from, they rarely convey the origin location of each batch of food involved in the shipment to meet the “traceability lot code source” requirement of FSMA 204. This may mean that most legacy EDI ASN implementations will need to be upgraded.
More and more companies are now putting QR codes onto their products and pallets. GS1, the non-profit standards organization, has defined a new open standard for barcodes called “GS1 Digital Link” that replaces the traditional 1D linear barcode with a 2D QR code that contains a web address built from the same fundamental GS1 identifiers, such as GTIN, Batch/Lot Number, and Serial Shipping Container Code (SSCC). Learn all about the GS1 Digital Link standard in our guide here.
This mechanism provides opportunities for receivers to “pull” data about a shipment from the systems of the provider. For example, a manufacturer could put a QR code on a pallet, and the receiver could then scan the QR code and download the shipping, contents and origin data onto their device:
The downside of this of course is the labor costs and potential for mistakes when downloading and manipulating data manually. A more automated approach that avoids manual data manipulation is to have a system scan the web address from the QR code and then perform API calls to fetch further CTE and KDE data in electronic GS1 format. TrackVision provides all the capabilities needed by both parties to set up a scheme like this:
The last way of exchanging data is the most obvious and the oldest way… send human readable data in the format of your choice via email or as printed out paper documents. For example, you could send an email to your business partner containing a spreadsheet with the CTEs and KDEs required by the legislation that correspond to the shipment you are sending them. While this method may appear cheap and easy for the sender, it can be costly for downstream business partners, as they will have to employ someone to process the spreadsheets and enter the data into their own system. The manual nature of the work also increases the chances of errors, which could cause a problem during an FDA food incident investigation. And because standards are not being used, the more suppliers the receiver has, the more variations and labor the receiver needs to deal with - the method doesn’t scale. But still, this method does have a place for certain situations. TrackVision AI is an example of software that will allow you to automatically send these FSMA related emails.
In this article, we’ve learned the exact data exchange requirements stipulated by section 204(d) of the Food Safety Modernization Act, during the Harvesting, Cooling and Shipping business steps. We’ve also learned how electronic data exchange based on GS1 standards plays a vital role in ensuring data is exchanged cost-effectively and accurately at scale, without incurring labor costs.
At TrackVision AI, our company was founded to make data exchange using the latest GS1 standards simple, whether you are a small, medium or large business, and whatever role you play in the supply chain. We provide all the capabilities you need to comply with FSMA 204, including master data management, scanning, label printing, data analytics, and data exchange based on your preferred method, including EPCIS, EDI, Digital Link or even email. Contact us today for a free consultation on FSMA and how you can comply using best practice GS1 standards.
Join our newsletter today and don't miss out on the opportunity to be part of a community driving innovation in tracking technology.
Sign up now and be in the know!