9 replies to this topic

[Frank88maurice]

Hi all!!

 

could any one help with this?

Thanks!

 

What is the difference between a testing of your recall withdraw program VS a traceability excersize?

 

 

Second Question is

 

What is an internal systems audit and what does it include?

 

 

 

thanks for your time!

[Charles.C]

Hi all!!

 

could any one help with this?

Thanks!

 

What is the difference between a testing of your recall withdraw program VS a traceability excersize?

 

 

Second Question is

 

What is an internal systems audit and what does it include?

 

 

 

thanks for your time!

Dear frankmaurice,

 

I presume you are referring paras  3.11, 3.9.x et al respectively (added later - apologies, I must have imagined this was in BRC forum but most of the subsequent posted comments are anyway generic).

 

This topic has generated a lengthy history on this forum. Particularly due overlap between traceability / mock recalls / recalls as interpreted in different locations and standards.

 

I suggest you consult for both issues  –

 

http://www.ifsqn.com...dit/#entry63995

 

http://www.ifsqn.com...532/#entry62551

(and the threads sub-linked within)

 

One brief conceptual answer to "difference" (thread also included in above links) is –

 

http://www.ifsqn.com...nts/#entry59282

 

The “internal audit” has an even greater collection of threads here.

One quick answer is that it involves generating a checklist of yr system within the context of the BRC standard. This is effectively the same as a “Gap-list” which you are probably familiar with. Then add (or combine) a corrective actions procedures for following up audit results. Many factories split the audit into sections so it can be covered, for example, in a 12-month time-frame. Some users incorporate a specific risk-based prioritization from existing data.

 

Rgds / Charles.C

[bacon]

There is always endless confusion about this issue it seems.

 

In my experience, the concept of Recall vs. Traceability have been defined by the terms of "Mock" recall vs. Traceability.

 

RECALL: In a BRC audit, one would do a mock recall to something (tracking a particular lot for some reason or an incident covering many lots) by "calling it back" by "tracing" it all the way to sales and where the product went and demonstrate our ability to notify a recall (with all the lot details sold) to the end consumer (often the Retailer). Mass Balance can come into play as one must prove (by providing that the "recovery" or "yield" is reasonable) that you have captured all of the product.

 

TRACEABILITY: My experience with a Traceability Exercise (via BRC) is a bit different. It can be more extensive in documentation. In short, pick a raw material (ingredient/packaging/protein) batch and gather all documentation associated with it. This will ultimately provide a path for root cause if warranted.

 

In addition, as VeilleAlim states on traceability in the link above the Charles.C references, this will encompass more documentation such as:

 

"- Suppliers of raw materials, evaluation of those suppliers

- Technical datasheets, and control on delivery of raw materials

- Production scheme

- Process checks (cleaning, CCP, glass, metal,...)

- Clients, Technical data sheet of finished product, ...

- Control on loading and on delivery,...

- Medical screening and training of people who signed the documents"

etc.

 

Mass Balance comes into play here also: i.e. - lot of ingredient picked, where is came from, how much ordered, how much on hand (indicating how much used), what products it went into, where those products went, calculate how much of said ingredient used, calculate yield/recovery: is the "loss" explainable? Explainable by an internal or external industry standard?

 

Now, this is my experience, and it has always seemed to make sense and convince a 3rd party auditor.

Anybody else take on this?

[Charles.C]

Dear baron,

 

Apologies for slightly indirect continuation to yr post. i will try to "simplify" the overall context to yr specifics since i hv personally found this part the first conceptual hurdle to struggle with. Hopefully, FrankMaurice will "go with the flow".

 

No doubt this is a non-simple pair of topics.

 

It is also undoubtedly variable with regard to local, legal and other (eg FS standards) expectations.

 

I recently came across this Irish “Guidance” document  which I don’t recall seeing here before. Occasionally intricate but very readable / well presented IMO.

 

 tr1 - Product Recall and Traceability, 2013.pdf   335.92KB   836 downloads

 

The document attempts (in 68pgs) to present the EC perspective, noting the legal / non-legal but “best practices” involved.

Has been updated to 2013, presumably in particular view of recent, well-documented incidents, eg beef, sprouts.

Seems to (generically) consider many  (all?) of the aspects discussed in this forum although not specifically designed with private standards in mind  so that detail for specific elements (eg previous post) is variable. I suspect mesophile’s document corresponds to the width of the BRC interest. No doubt “diligence” is a UK potent factor, not to mention Lasagne.

 

I hv extracted a few sample portions for illustration :

 

Definitions

Traceability

The ability to trace and follow a food, feed, food producing animal  or  substance  intended  to  be,  or  expected  to  be incorporated  into  a  food  or  feed,  through  all  stages  of  production, processing and distribution.

 

Recall

The removal of an unsafe food from the market when it may have reached the consumer and the notification of the consumer.

 

 

OBJECTIVES OF A FOOD TRACEABILITY SYSTEM

 

There are two objectives of a food traceability system:

 

1. To identify uniquely, a batch of food and the raw material batches used in its production, in a way which allows tracking the physical flow of the food forwards through the food chain to the immediate customer and tracing of the physical flow of raw materials backwards to the immediate supplier .

2. To create and maintain accurate traceability records that can be provided within a short time period for routine examination or investigation purposes at the demand of the competent authorities.

 

 

KEY STEPS IN DEVELOPING FOOD TRACEABILITY SYSTEMS

Step 1. Define the scope of the traceability system

Step 2. Decide on the optimal batch size

Step 3. Identify the traceability information needed, including:

• Information    that must accompany food ingredients used by the food business operator.

• Internal process information that is needed      to maintain traceability through food      processing or preparation where applicable.

• Information that must accompany distribution of the food produced by the food business operator

Step 4. Establish a system of record keeping and retrieval

Step 5. Establish procedures for review and testing of the traceability system

Step 6. Document the traceability system

 

 

STEP 1. SCOPE OF A TRACEABILITY SYSTEM

Food business operators should define the scope of their traceability system before developing it. Traceability systems are composed of one or more of the following three elements, depending on the nature of the food business:

a) Supplier traceability: traceability of the suppliers of food and packaging to the food business operator. Supplier traceability is a legal requirement for all food businesses.

b) Process traceability: traceability of food and packaging through the operations within the food business operator’s establishment whether or not new products are produced. (Note: this is not a legal requirement but is best practice).

c) Customer traceability: tracking the food leaving a food business operator’s establishment to the immediate customers receiving it. Customer traceability is a legal requirement for all food businesses except when food is only sold directly to the final consumer.

Attention  must  be  given  to  the  interface  between  the  three  elements  to  ensure  that  the traceability system is seamless.

 

Process traceability is not a legal requirement for any food business but is best practice. It is recognised  that  if  businesses  are  small  with  single  product  lines  or  simple  processes,  process traceability  may  not  be  needed.  However,  best  practice  includes  process  traceability  where relevant in the scope of the traceability system, because in many circumstances, food business operators risk more extensive and damaging withdrawals or recalls if their traceability systems do not incorporate process traceability.

 

 

Haven’t done any detailed searching but in comparison to EC, the US situation / elsewhere seems more fragmented.  I did not see any published generic traceability documents, eg  ex  FSIS, FDA ??. The current  US scenario is maybe as per this 2012  file inspired apparently by  FSMA’s coming requirements.

 

 tr2 - IFT - FDA Report on Recall and Traceability, 2012.pdf   5.52MB   496 downloads

 

Rgds / Charles.C

[bacon]

The tr1 - Product Recall and Traceability, 2013.pdf is rather good and what I have roughly followed. I now note that I failed to mention in a Mock Recall plan, recall contact information [internal, customer, etc]. A recall can be identified and isolated in many different ways (from a customer illness, from a supplier recall, an internal non-conformity, etc).

 

However, one thing I think is missing is the Mass Balance calculation, the only way one can really identify if all of a "raw material batch" has been captured in a trace exercise or a mock recall.

 

I have not slogged through the tr2 - IFT - FDA Report on Recall and Traceability, 2012.pdf, but it does mention Mass Balance but not the mechanics of doing so.

 

Both good reads, Thank you Charles.

 

Frank88maurice, I think the 1st article should give you rather good guidance. But be aware of conducting a Mass Balance as the way to verify that all the product was identified: in a Recall in terms of lot production weights vs. customer receipts, in Traceability in terms of original receipt and weights vs.customer receipts. There may be different scenarios that can occur to mix this up, but one wants to ultimately prove that everything can be accounted for and identified as to current disposition.

 

Cheers,

-B

[Charles.C]

Dear baron,

 

Yes, I agree that mass balance is “understood" as far as tr1 / process traceability is concerned. It was also a later addition to the BRC standard from memory. ( I think the AIB file in an earlier post is the only one where I hv seen any actual semi-worked example so far).

 

IMEX, most Production Departments are highly focused on monitoring / quantitating “wastage” in every direction and of every kind but particularly process materials, whatever the cause. Notification of over- consumption of toilet rolls can get a little irritating though.

 

Offhand, I think none of the practical “mock recall” examples I hv seen here included perusal of mass balance documentation (?). Although it obviously could do. (added later - predictably I immediately found an exception with a discussion pro/con following, see  -

 

http://www.ifsqn.com...rc-clause-532/

 

In contrast, I would have thought a mass balance would inevitably  be involved in a formal “recall”.  It is implied in Step3 of the Recall Process in tr1.

 

Rgds / Charles.C

 

@FrankMaurice:  So to answer yr original question, IMO quite a lot !. i suggest you hv a look at some of the typical forms for documenting "mock recall" examples in previous links and compare with the details in, for example, BRC's listed traceability requirements. May well depend on yr actual standard of course, eg the definition of a "mock recall".

[bacon]

A not on wastage tracking: Yes, I agree, Production tends to be highly focused on monitoring wastage....

 

But please note that when it comes to a long term inventory ingredient like Black Pepper in RTE foods that is used in many items but in low quantity (and doesn't cost very much): Production is not so concerned with monitoring wastage on this item.

 

However, if one has done a risk assessment on food ingredients, people may remember this block of recalls the US back in 2010:

 

http://www.foodsafet...k/#.Unv4bOLN2-M

 

And even last autumn 2012 in Europe (Belgium) there was a Salmonella recall for black pepper...

 

Just saying, do the most difficult/complex/high-risk items in your mock recall to test ones tractability system. I have and it did wonders to get senior management motivated to improve their Traceability tracking.

 

-B

[Simon]

This is what Tony Connor once told me:
 

Forward traceability - this is taking a batch of raw material and tracing through the process, including intermediate products/work in progress to all the finished products that were made with that raw material. 

Backward traceability - this is taking a finished product batch and tracing back from customer, back through the process including intermediate products/work in progress to batches of raw materials used. This is specific for the finished product batch.

 

 

So you should test the traceability system both ways every once in a while.

 

Mock recall is simulating a food safety problem, with the product recall team and involving relevant customers to test, refresh and identify weak areas and opportunities for improvement.

[shather]

Hi All,

 

I have just joined the community and noted some great information in some of the replies. Unfortunately I need to post a few more times before I can download and read the files people have referred to.

 

I just wanted to comment on the original question - the difference between the test of a recall program and a traceability exercise.

 

I am a product recall and crisis management consultant and was a member of the working group that developed the recently released international standard for product recall (ISO 10393) and its "sister" standard on product safety (ISO 10377). I am involved in dozens of product-related incidents every year, some of which lead to recalls. I am happy to say that none that I have been involved with have led to a crisis which I define as an incident that has escalated to to point of having significant negative impact on company's reputation and brands. There are many examples of recalls that do escalate into a crisis - the Fonterra crisis being perhaps the one with the most headlines after its (former) key customer announced it was cancelling its multi-million dollar supply contract and suing for $500m in losses.

 

Many companies conduct "mock recalls" which is generally a traceability exercise. This is really important and we certainly encourage our clients to conduct these as well. Most audits require it. They are generally not however a test of a product recall program. A simple recall incident - where there is clearly a health and safety risk, the product is recalled, the right people are notified and there is very little publicity, is something that most companies should be able to manage effectively with a solid plan and people that can use it. Where we find companies struggle - and where incidents quickly escalate into crisis is where the hazard is not so cut and dried or the first time they find out about a potential problem is when it goes viral on social media, or companies are forced kicking and screaming into a recall situation by a regulator or after negative media reporting. In our experience if you get the 5 key elements of an effective recall program right, the implementation tends to flow reasonably smoothly. Get them wrong and a crisis becomes much more likely. The 5 key elements are notification, investigation, assessment, strategy and communications. 

 

A test of your recall program - the plan, people and practice;  should involve a full test of all these elements. You might get the notification part right -everyone knows a test is on so they are on stand-by to make sure the right people get the information quickly!, probably get the investigation right as this is bread and butter for good QA managers but often don't test the assessment, strategy and communication parts including addressing stakeholder concerns and expectations. We do a lot of recall and crisis simulation exercises and the key area that people struggle with is managing external stakeholders - customers, regulators, media who rarely do what you expect them to do. This is why assessment, strategy and communications is key to preventing crises.

 

So the difference between testing a recall program and a traceability exercise is scope. A test of recall program involves all elements as well as role playing external stakeholders. A traceability exercise tests one part, albeit it a key part, of your investigation process. 

 

Steve Hather

Edited by Charles.C, 04 February 2014 - 02:30 AM.
URL removed

[Charles.C]

Dear shather,

 

Welcome to the forum !

 

Thanks for yr interesting post.

 

Unfortunately I need to post a few more times before I can download and read the files people have referred to.

 

AFAIK, this is incorrect except for files located in the "File Library". The rest should be immediately available. Please try again.

 

I am happy to say that none that I have been involved with have led to a crisis which I define as an incident that has escalated to to point of having significant negative impact on company's reputation and brands.

This of course is a very subjective definition. IMEX many customers will strongly disagree.

 

 

Many companies conduct "mock recalls" which is generally a traceability exercise. This is really important and we certainly encourage our clients to conduct these as well. Most audits require it. They are generally not however a test of a product recall program

 

As discussed in the  thread, this may well depend on definitions / interpretations / objectives. I'm unsure what you are defining as "traceability".

As you probably noticed, many (probably most) threads / audit queries here are generated via private Food Standards. At least one standard (BRC) has a text which seems to categorically distinguish the 2 elements. From memory, others are less precise. Audit  experiences reported here seem to mostly require separation (albeit not always in the same way). However fusions of the two concepts  certainly occur also as referenced in these threads. Frankly at the moment there appears to be no consensus on   "standard" definitions as far as I can see. Similar to geographical variations in the implementations of so-called "Product Recalls".  Perhaps yr own apparently varying experience to above is related to main area of activity ?.

 

 

So the difference between testing a recall program and a traceability exercise is scope. A test of recall program involves all elements as well as role playing external stakeholders. A traceability exercise tests one part, albeit it a key part, of your investigation process.

 

I certainly agree that scope of "something" is involved. The following sentences are, IMO, a matter of opinion and possibly definition. And standards ?.

 

Rgds / Charles.C