How do you audit for compliance with ISO 14971:2012?

Let’s say that you went ahead and purchased ISO 14971:2012, read Annex ZA, and you identified a couple of gaps in your procedure. After you revised your Risk Management Procedure to be compliant with the revised Standard, then what are you supposed to do?

For the next few weeks I plan to torture all of you with holiday music. If you don’t like it, buy a satellite radio for Christmas sake.

Most QA Managers struggle over whether they should purchase ISO 14971:2012 or not. I wrote a couple of blog postings about this, but my point was not to debate this question. My point was that companies need to be compliant with the MDD and the ISO 14971 Standard. The “changes” from the 2009 to the 2012 version are simply the European Commission reminding manufacturers that there are 7 aspects of the ISO 14791 Standard that  do not meet the requirements of the MDD. Therefore, if your company has already verified that your Risk Management Process is compliant with the MDD–then you have nothing to change. However, if your Risk Management Process is only compliant with ISO 14971:2009, then you need to revise your processes and procedures to address these 7 aspects.

Once you have made your revisions, how do you audit for compliance with ISO 14971:2012?

Step 1: Planning the Audit

This will be an internal audit and since you (the QA Manager) are the process owner for the Risk Management process, you cannot also audit this process. You need to assign someone that has the technical skill to perform the audit, but this person cannot be the process owner (you) or a direct report to the process owner (the rest of the QA department). Fortunately, the Director of Engineering is also trained as an internal auditor at your company. She is trained on ISO 14971:2009, but she is not trained on ISO 14971:2012. To address this gap, she must read the updated Standard to understand what’s new.

Clause 3.2 of ISO 14971 requires that top management review the Risk Management Process for Effectiveness.

She has participated in risk management activities, but each product development engineer participates in risk management activities for their own design projects. Therefore, she has several projects she can sample risk management records from without auditing her own work. You have communicated that you need this audit finished sometime in December, because you want any CAPA’s resulting from the audit to be finalized before the next Management Review at the end of January. The timing of the Management Review is important, because the Risk Management Procedure requires that top management assess the effectiveness of the Risk Management Process during Management Review meetings.

There are no previous audit findings to close from the last audit of the Risk Management Process, but the Director of Engineering has 7 specific items to emphasize from the 2012 revision of the Standard and a revised procedure for Risk Management. Therefore, she will prepare for the audit by identifying some new interview questions to specifically address these changes–as well as some more generic, open-ended questions.

Specific Questions for 7 Items in ISO 14971:2012, Annex ZA:

1. How does the risk analysis evaluate the acceptability of risks in the lowest category? (This is a leading question, but it is specifically designed to determine if negligible risks are discarded.)

2. Please provide a few examples of how risks in the lowest category were reduced. (Sections 1 and 2 of the Annex I require all risks to be reduced as far as possible, and for all risks to be evaluated for acceptability. The wording of this question also allows auditors flexibility in their sampling.)

3.  How did the design team determine when they had implemented sufficient risk controls to minimize risks? (Many companies use a color-coded matrix as a quasi-objective method for determining when risks are adequately reduced. This process is often referred to as the ALARP concept. Annex ZA specifically prohibits using economic considerations as part of this determination.)

4. How did you conduct a risk-benefit analysis? (The Standard allows for performing a risk-benefit analysis when overall residual risks exceed the acceptability criteria as outlined in the risk management plan. However, the MDD requires an overall risk-benefit analysis in Section 1 of Annex I. Section 6 also requires that a risk-benefit analysis be performed for each individual risk.)

5. How were risk control options selected? (Section 2 of the MDD implies that the manufacturer shall review All the control options and pick the most appropriate ones. Therefore, the auditor should specifically look for evidence that the team systematically reviewed all possible control options to reduce risks–rather than stopping as soon as the risks were reduced to an acceptable level.)

6. What were your team’s priorities for implementation of risk control options? (It’s possible that the previous question will be sufficient to gather evidence that risk controls were implemented with the required prioritization as specified in the MDD. However, this question would be used as a follow-up question if it is not clear that the team prioritized the risk control options in accordance with Section 2 of Annex I.)

7. How was effect of labeling and warnings in the instructions for use incorporated into the estimation of residual risks? (Almost every company remembers to include residual risks in their IFU as a warning or caution statement. However, Section 2 of Annex I does not allow for including this information given to the users as a method of reducing risks. Therefore, in a Design FMEA you would not list labeling and IFUs in your column for current risk controls when you determine the risk. This should be identified as an action to be taken–with no impact on the score for residual risk.)

The above questions are not examples of using the process approach, but each question is phrased in an open-ended manner to maximize the objective evidence gathered during the interview process. If you are doing a process audit, it’s still ok to include questions that use the element approach.

Generic Questions:

1. When was the ISO 14971:2012 version of the Standard added to the controlled list of external Standards?

2. Please provide examples of where you have updated the Essential Requirements Checklist (a Technical File document) to reference the newest revision of ISO 14971:2012, and please show at least one example of how the Risk Management Report was updated to reflect this revision.

3. How did you verify training effectiveness for the design team specific to the updated Risk Management Procedure prior to conducting a risk analysis?

These generic questions do not require reading the ISO 14971:2012 Standard. Instead, each question forces the auditee to demonstrate their knowledge of the revised Standard by asking open-ended interview questions. Each of these questions is also designed to test linkages with other support processes. This is an example of how to use the process approach.

Step 2: Conducting the Audit

The next step of the auditing process is to conduct the audit. During the audit, the Director of Engineering will gather objective evidence of both conformity and nonconformity for the risk management process. The generic interview questions that were developed allow her to evaluate the effectiveness of linkages between the Risk Management Process and other processes such as: 1) document control, 2) creating technical documentation for regulatory submissions, and 3) the training process. The specific questions verify that each of the 7 elements identified in Annex ZA of ISO 14971:2012 are adequately addressed in the revised procedure. When the audit is completed, the auditor will have a closing meeting with the process owner (you) and the auditee(s) so that everyone is clear what the findings were, and if there were any nonconformities this is the time to clarify what needs to be done in order to prevent each nonconformity from recurring.

Step 3: Writing the Report & Taking Corrective Action(s)

This is no different from any other audit, but it is critical to have the report completed soon enough so that CAPA’s can be initiated (not necessarily completed) prior to the Management Review.

Step 4: Verifying Effectiveness of Corrective Action(s)

Many people struggle with verifying effectiveness of corrective actions–regardless of the process. My advice is to identify a process metric to measure the effectiveness. Then the effectiveness check is objective. For example, monitoring the frequently of updates to the list of external standards can help verify that the process for monitoring when Standards are updated is effective. Likewise, the frequency of updates to the Essential Requirements Checklist and the Risk Management records referenced in the Essential Requirements Checklist indicates if the Risk Management process is  being maintained. Finally, monitoring the lag between the time procedures are updated and when the associated training records are updated quickly identifies if there is a systemic problem with training or if a train gap is just an example of a single lapse.

Advertisement

ISO 14971 – Buy the new 2012 version?…comment please

I’m sure that there are some that disagree with my determination that the latest revision of EN 14971, revision 2012, is unnecessary (the European Commission certainly does).

 You will have to go to my website to read my cheeky posting on this topic.

And here’s another cheeky attitude from the UK…(sorry, this is not a family channel).

Therefore, I would like to clarify why I feel this way by reviewing how risk is addressed in the MDD (93/42/EEC as modified by 2007/47/EC).

1. The term risk is mentioned only 4 times in the Articles in the MDD
2. The term risk is mentioned once in Annex II and III, twice in Annex VII, and three times in Annex VIII and X—for a total of 10 times.
3. The other 41 times risk is mentioned are in the Essential Requirements (i.e. – Annex I).

When companies submit a Design Dossier for review by a Notified Body, an Essential Requirements Checklist is included. This references, in table format, how all the requirements of Annex I are being met—including those related to risks. Throughout Annex I, a similar phrase is repeated many times. For example, in the first Essential Requirement (ER1) it states: “…any risks which may be associated with [a device’s] intended use [shall] constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety.” In ER2 it states: “the manufacturer must…eliminate or reduce risks as far as possible…”. There is no room in the MDD for consideration of cost or economic impact when the manufacturer is designing a device with regard to risks and benefits.

If a company’s Risk Management Procedure has been found to be acceptable by a Notified Body, and the company has addressed all the Essential Requirements (ERs) with regard to risk, then there should be no impact from these 7 deviations identified in EN 14971:2012. However, if your company has not addressed each of these ERs, then you might want to consider each of these areas:

1. Treatment of negligible risks
2. Discretionary power of the manufacturer as to the acceptability of risks
3. Risk reduction “as low as possible” (ALAP) verses “as low as reasonably possible” (ALARP)
4. Discretion as to whether as risk benefit analysis needs to take place
5. Discretion as to the risk control option/measures
6. Deviation as to the first risk control method
7. Information of the users influencing the residual risk

My final advice is to review Annex I and Annex X from the perspective of risk management. You may realize that you have some gaps that nobody noticed. After all, audits are just a sample.

PS – I think it’s ironic that the origins of the ALARP principle are UK case law (see link above).

What is the Design Input?

Micky, this is for you.

I have been directly involved in dozens of design projects throughout my career, and during the past three years I have audited 50+ Design Dossiers for CE Marking of Medical Devices. Throughout most of these design projects, I have noticed one common thread—a misunderstanding of design inputs.

ISO 13485 identifies the requirements for Design Inputs. These requirements are:

1. Functional (7.3.2a)
2. Performance (7.3.2a)
3. Safety (7.3.2a)
4. Statutory / Regulatory (7.3.2b)
5. Previous and Similar Designs (7.3.2c)
6. Essential Requirements (7.3.2d)
7. Outputs of Risk Management (7.3.2e)
8. Customer Requirements (7.2.1)
9. Organizational Requirements (7.2.1)

The most common error seems to be the failure to include the outputs of risk management. For those of you that have used design FMEA’s—that’s what the right-hand columns are for. When you identify suggested actions to mitigate risks with the current design, these actions should be translated into inputs for the “new and improved” model.

The second most common error seems to be failure to consider regulatory requirements. There are actually two ways this mistake is frequently made: 1) Canadian MDR’s were not considered as design inputs for a device intended for Canadian medical device licensing, and 2) an applicable ISO Standard was not considered (i.e. – “State of the Art” is Essential Requirement 2 of the Medical Device Directive or MDD).

The third most common error, and the one that drives me crazy, is confusion of design outputs and design inputs. For example: an outer diameter of 2.3 +/- 0.05 mm is not a design input for a 7 French arterial catheter. This is a design output. The user need might be that the catheter must be small enough to fit inside the femoral artery and allow interventional radiologists to navigate to a specific location to administer therapy. Validation that the new design can do this is relatively straight forward to evaluate in a pre-clinical animal model or a clinical study. The question is, “What is the design input?”
Design inputs are supposed to be objective criteria for verification that the design outputs are adequate. One example of a design input is that the catheter outer diameter must be no larger than a previous design that is an 8 French catheter. Another possible design input is that the catheter outer diameter must be less than a competitor product. In both examples, a simple measurement of the OD is all that is required to complete the verification. This also gives a design team much more freedom to develop novel products than a narrow specification of 23 +/- 0.05 mm allows for.

If you are developing a Class II medical device for a 510(k) submission to the FDA, special controls guidance documents will include design inputs. If you are developing a Class IIa, Class IIb or Class III medical device for CE marking, there is probably an ISO Standard that lists functional, performance and safety requirements for the device. Regulatory guidance documents and ISO Standards usually reference test methods and indicate acceptance criteria. When you have a test method and acceptance criteria defined, it is easier to write a verification protocol. Therefore, design teams should always strive to document design inputs that reference a test method and acceptance criteria. If this is not done, verification protocols are much more difficult to write.

In my earlier example, the outer diameter of 2.3 +/- 0.05 mm is a specification. Unfortunately, many companies would document this as an input and use the final drawing as the output. By making this mistake, “verification” is simply to measure the outer diameter to verify that it matches the drawing. This adds no value and if the specifications are incorrect the design team will not know about it.

A true verification would include a protocol that identifies the “worst-case scenario” and verifies that this still meets the design input requirements. Therefore, if the drawing indicates a dimensional tolerance of 2.3 +/- 0.05, “worst-case” is 2.35 mm. The verification process is to measure either a previous version of the product or a competitor’s catheter. The smallest previous version or competitor catheter tested must be larger than the upper limit of the design output for outer diameter of the new catheter.

Never Stop Learning

One of my family’s favorite songs is “Come on Get Higher” by Matt Nathanson. Two years ago I tried to purchase this for my wife as a Christmas present. Unfortunately, I couldn’t remember who sang the song. I tried searching the web for the lyrics and found out that Sugarland sings it. I remembered the logo on the album cover, went to the store and bought the album. After I got home I realized that the song wasn’t on the album. Back to the store I went and found another version of the album with some live versions of songs—including “Come on Get Higher.” Just to make sure I had the right song, I decided to open the package and play it. My music video selection for this blog is what I heard. I guess we never stop learning, but I did fall in love with Country music at the age of 38…

I am in Canada, it’s almost midnight, and this client has me thinking so hard that I can’t sleep. I am here to teach the company’s Canadian facility about ISO 14971:2007—the ISO Standard for Risk Management of medical devices.

                Most of the companies that request this training are doing so for one of two reasons: 1) several of their design engineers know almost nothing about risk management, or 2) they have several design engineers that are quite knowledgeable with regard to risk management but these engineers have not maintained their credentials and their last risk management training was to the 2000 version of the Standard. This company falls into the second category.

                I always tell students that I learn something by teaching each course. From this company, however, I have learned so much. This company has forced me to re-read the Standard a number of times and reflect on the nuances of almost every single phrase. I have learned more about this Standard in one month than I learned in the 3.5 years since I first took the course I am now teaching.

                I have developed a model for learning that explains this phenomenon. I call this model the “Learning Pyramid.” At the base of the pyramid there are “Newbies.”

               This is the first of four levels. At the base, students read policies and procedures with the hope of understanding.

                In the second level of the pyramid, the student is now asked to watch someone else demonstrate proper procedures. One of my former colleagues has a saying that explains the purpose of this process well, “A picture tells a thousand words, but a demonstration is like a thousand pictures.” This is what our children call “sharing time,” but everyone over 40 remembers this as “show and tell.”

                In the third level of the pyramid, the student is now asked to perform the tasks they are learning. This is described as “doing,” but in my auditing courses I refer to this process as “shadowing.” Trainees will first read the procedures for Internal Auditing (level 1). Next trainees will shadow the trainer during an audit as a demonstration of proper technique (level 2). During subsequent audits, the trainees will audit and the trainer will shadow the trainee (level 3). During this “doing” phase, the trainer must watch, listen and wait for what I call the “Teachable Moment.” This is a moment when the trainee makes a mistake, and you can use this mistake as an opportunity to demonstrate a difficult subject.

                Finally, in the fourth level of the Learning Pyramid we now allow the trainee to become a trainer. This is where I am at—so I thought. I am an instructor, but I am still learning. I am learning what I don’t know.

                The next step in the learning process is to return to the first level. I am re-reading the Standard and procedures until I really understand the nuances that I was unaware of. Then I will search for examples in the real world that demonstrate these complex concepts I am learning. After searching for examples, I will test my knowledge by attempting to apply the newly acquired knowledge to a 510(k) or CE Marking project for a medical device client. Finally, I will be prepared to teach again.

                This reiterative process reminds me of the game Chutes and Ladders, but one key difference is that we never really reach the level of “Guru.” We continue to improve, but never reach our goal of perfection…For further inspiration try reading “Toyota Under Fire.”

The Perfect Pecan Pie – My Risk Management Plan

I hope everyone enjoys this selection for the music video. It’s one of my favorite songs by Sting—mostly because it seems to be more upbeat than many of his other tunes. I can almost hear him smiling as he wrote the lyrics.

                This blog posting is a continuation of my previous post on the subject of Risk Management Training, specifically the ISO 14791:2007 Risk Management Standard. In my Risk Management Training, I use the example of making “The Perfect Pecan Pie” as a practical example of applying the principles of Risk Management.

                The first step of the Risk Management Process, or any process, should be planning. My personal preference for planning Risk Management is to begin by brainstorming in order to create a list of potential Quality issues. During the brainstorming session, I will use a Cause & Effect Diagram (a.k.a – “Fishbone Diagram”) to ensure that I have covered as many of the important issues as possible. For those that are unfamiliar with this tool, there are six categories of causes for any problem. These are sometimes referred to as the six “M’s”, because each category begins with the letter “M”:

1)      Materials

2)      Method

3)      Machine

4)      Measurement

5)      Manpower

6)      Mother Nature

                Materials are the single most important component of any product. As the saying goes, “Garbage in equals garbage out.” The right, fresh ingredients are just as important to baking pies as biocompatible materials are to manufacturing implantable medical devices. For example, stale pecans are plain nasty; while granular sugar produces a sickeningly, sweet syrup. Pecan pies are derived from “chess” pies—pies that were cheese-like due to the custard consistency created by cooking butter, eggs, milk and sugar at a low temperature. Therefore, the filling of a pecan pie requires a six tablespoons of unsalted butter, three large cage-free eggs (size matters—don’t get extra large), one cup dark brown sugar (light brown is also too sweet), three-quarters cup light corn syrup, one tablespoon natural vanilla (artificial vanilla tastes totally different and overwhelms the praline flavor), and one cup of pecan halves (I’m told that Georgia pecans picked fresh from the tree are amazing, and roasting them enhances the flavor even more.).

                Manufacturing processes are always the second most important factor related to Quality. For the “Perfect Pecan Pie,” this is also true. Most people will try making their first pie by cooking the filling and the pie crust together. This can produce acceptable results if you are extremely lucky. For custards, however, it is much easier to get consistently beautiful pies by pre-cooking the pie-shell (and sealing it with egg yolk) and pre-cooking the filling separately in a double boiler (always use the right machine for the job). Once the filling gets to the desired temperature (~130F) then the filling should be poured into the pre-cooked crust for the final baking. The final baking should be at 275F for one hour (at sea level).

                If you choose to deviate from any of the above directions regarding the manufacturing process, good luck finding a material review board to approve the release of your pie. If you don’t seal the pie crust, it will leak and you will never get be able to serve an intact slice of pie. If you don’t use a double boiler, you get a mixture of caramel and burnt candy. If you overcook the filling, the consistency will be off. If you undercook the filling, the pie will be uncooked…another way to make it impossible to serve an intact slide of pie.

                When you are cooking a soup, stew or some other dish, measuring is a forgiving process. For baking, the ratio of ingredients, the degree of mixing, and the temperature for baking are critical. Any deviation usually leads to a disaster.

                The next category, manpower, addresses the issue of training. You would think that baking is all about skill. However, like all validated manufacturing processes, proper use of process controls can transform the most inept person into a brilliant baker. Most people struggle with the crust. Packard Consulting, however, has developed a fool-proof method for making a crust. The key is to cool the dough ball and press it into a glass pie dish. The reason for a glass dish is so that you can hold the uncooked shell up to the light to inspect it for “thin spots.” Then you cover the shell with foil, poke it several times with a fork to allow it to vent, bake it for 15 minutes at 400F, uncover it, brush it with egg yolk to seal the crust, and continue baking it for 10 more minutes—or until the crust is a golden brown on the edges.

                Finally, the oven temperature is most critical for the final baking—after pouring the pre-cooked filling into the pre-baked pie crust. In this case, we have an artificial environment (i.e. – Mother Nature). Unfortunately, very few ovens are calibrated accurately and the temperature is very inconsistent throughout the oven. Ovens are hottest on the top rack and the back of the oven is always hotter than the front. Therefore, you need to rotate the pie during the baking process or it gets cooked unevenly. Another critical step is to “map” the oven temperature. You must determine where in the oven (i.e. – which rack position) to place the pie when the oven is set at 275F. In some ovens, the temperature is so far off that it is necessary to raise or lower the setting by 15 degrees.

                Now that I have given you the recipe for the “Perfect Pecan Pie,” you might be tempted to make one. Before you do, I recommend getting a piece of paper and documenting every step you take—including any visual observations, the taste of the dough, and the taste of the filling. This information will become your risk management file. As you perfect your technique, learn the idiosyncrasies of your kitchen appliances, and you find sources for each ingredient…you will need to prevent these secrets from becoming lost. Your collection of notes is a Risk Management File.

                You have now completed Section 3 of the 14971:2007 Standard. Keep drooling and I promise to serve up another slice:)

 PS – Here’s a cool drumming lesson that gave me a much better appreciation for the layers of rhythm within the song I chose for this blog’s background entertainment.

The Perfect Pecan Pie – Recipe # 14,971

Hats off to Woodson and the rest of the Packers! My team was the Patriots, but I’m happy to see that the Packers showed some real heart and overcame their injuries to win the trophy. As for the half time show…I thought it was more lights than music. I included a link to the half-time show at the end of this blog, but I thought the Black Eyed Peas video called “The Time (Dirty Bit)” is much more entertaining.

                For those of you familiar with the ISO 14791:2007 Risk Management Standard, you may have already figured out the topic of this blog. For the rest of you…did you really think I tried perfecting my recipe for pecan pie nearly 15,000 times?

                A couple of years ago, a client of mine asked me to give them a training course on Risk Management—specifically an overview of ISO 14971:2007. In my struggle to find a fresh way of engaging the interest of my client’s employees, I developed the concept of using the principles of Risk Management in a more tasty application. Back in 2006 I developed a five-minute presentation on how to make “The Perfect Pecan Pie.” For this new three-hour presentation, I tortured my students with a homemade pecan pie that I placed in the middle of the conference room table.

                This presentation included several tools to help my students remember the principles of Risk Management. First, the alliteration of the letter “P” throughout the presentation beat my message steadily into their subconscious. My second weapon was the smell of a warm, fresh, pecan pie. Third, I used analogies to the pecan pie making process for each aspect of the Risk Management Process. Fourth, I used vivid descriptions throughout my presentation to help everyone visualize the sweet, praline confection at each step of the baking process. And finally, I burned the experience into their brains forever with the taste of the Perfect Pecan Pie.

                Not everyone loves Pecan Pie as much as I do, and not everyone has tried making the Perfect Pecan Pie as many times as I have. I have made gooey pies, sickeningly sweet pies, pies that crack and crumble, pies that were barely cooked, pies without a crust, and pies without a filling. If you plan to coordinate your entire presentation around the concept of a homemade pecan pie you made in your kitchen last night, you had better have a proven Risk Management process to reduce the risk of embarrassing yourself.

                Please read my next several blogs as I unveil the secret to making the Perfect Pecan Pie—one slice at a time:)

                Here’s some of the half time show…(assuming the link is not taken down).

Risk Management – It’s Not My Job

There’s no deeper meaning to this week’s YouTube selection. I just thought I would share one of my favorite guitar soloists with you. The recording quality is only good, but just watching Tim play reveals how freakishly good he is. I highly recommend the live CD with Dave Matthews and Tim Reynolds. If someone knows of a better quality recording that I can post in my blog, please let me know.

Have you experienced a discussion similar to this?

Auditor: “How do you manage risk throughout the production process?”

Auditee: “That is the responsibility of our customers. We will prepare a risk analysis if customers pay for it, but usually customers do the risk analysis.”

Most contract manufacturers in the medical device industry exclude design from their Quality Management Systems. Unfortunately, most of the contract manufacturers also associate risk management with only the design process. Risk Management cannot be “not applicable” in an ISO 13485 Quality Management System. The requirement of section 7.1 is: “The organization shall establish documented requirements for risk management throughout product realization. Records arising from risk management shall be maintained.” The Standard also references ISO 14971 as a source of guidance on Risk Management.

                For a contract manufacturer, compliance with ISO 14971 is not my primary concern as an auditor. My primary concern is to verify that contract manufacturers analyze risks associated with the processes that they perform and do their best to minimize those risks. What I don’t understand is why more companies don’t want to have strong risk management process. Risk management is how we prevent bad things from happening. Bad things like scrap, complaints and recalls. Should we expect our suppliers to have a strong risk management process?

                Duh.

                Contract manufacturers should be doing everything they can to get better at risk management. During pre-production planning they should be asking, “What happens if…” The contract manufacturer knows best HOW things will fail in production, while the customer knows best WHAT happens when things fail in production. In order to be safe and effective, both companies need to collaborate on risk analysis.

                The reason companies avoid doing risk analysis is because it’s time consuming and tedious.

                 Too bad, so sad.

                 Balancing my checkbook is time consuming and tedious too, but I balance my checkbook to prevent an overdraft charge. Not doing risk analysis can be much more painful. Scrapping out a part can cost tens or hundreds of dollars. Complaints can cost thousands of dollars. Recalls can cost millions of dollars.

                If I owned a contract manufacturing company, I would make sure that everyone in the company is involved in risk management, because we don’t want scrap, we can’t afford mistakes that lead to complaints, and a recall will put us out of business.