The time to solve digital interoperability problems and help ensure a more transparent, interoperable and safe food system has come.
Within the next few years, the vision described in the FDA’s New Era of Smarter Food Safety blueprint can become a reality. In order to achieve it, we will need to tackle a devil hidden in many of the details, addressing challenges such as the food safety data interoperability one.
Let’s take a look at an example.
The US FDA regularly publishes information about certain recalls of FDA-regulated products. This information comes in a structured format, using the following data elements among others:
- Brand Name(s)
- Product Description
- Product Type
- Recall Reason Description
- Company Name
- Full recall text
Furthermore, the openFDA Food Enforcement Reports API returns data from the FDA Recall Enterprise System (RES), a database that contains information on recall event information submitted to FDA, updated on a weekly basis. It includes data elements such as:
- Recalling firm
- Product description
- Reason for recall
- Report date
- Recall initiation date
- Initial firm notification
- Product type
- Geographical location of firm (city, state, country)
In a similar way, the European RASSF – Rapid Alert System for Food and Feed is publicly announcing food and feed product recalls. This will enable information to be shared efficiently to ensure that food safety risks can be averted before they harm consumers. The RASSF portal is using data elements such as:
- Classification
- Notification date
- Date of case
- Reference ID
- Notifying country
- Product Category
- Type
- Risk decision
The list of examples goes on. There are many food safety agencies and national authorities that publish food product recalls using structured, well-documented and sometimes even machine readable data formats (such as the UK’s Food Standards Agency recall data API). Either in English or in their own languages (e.g. the Japanese NITE’s list of company announcements and recalls).
When trying to combine and aggregate food safety incident data coming from such official sources, a number of issues need to be resolved:
- How will the equivalent or similar elements of the different data formats be mapped to each other?
- How will the controlled lists of values be mapped to each other?
- Can mappings from one data format to another be standardized and reused every time a new incident s published?
- Can we then automate transformation from one data format to another using a software system?
These questions (and so many more) illustrate that food safety data interoperability is going to need a quite elaborate and sophisticated solution. To efficiently leverage data technologies and create a safer and more digital, traceable food system such challenges will need to be overcome.
I do not believe that we should aim to one food safety data standard to rule them all. The GFSI experience shows that there cannot be a single and unique solution to such a standardization challenge; we should rather put together a well-orchestrated food safety data benchmarking effort.
