Bench Testing

I've spent the last few weeks dealing with bench tests as we wait for other results to come in. Bench testing or performance testing gets stuck in section 18 of the 510(k), since it is in the back means they don't read it right? You will save yourself a lot of grief if you read the format guidance and make sure your protocols and reports line up nicely with their requirements, although you will need more than what is listed in the guidance, at least a scope.

For a small company there are several challenges to bench testing, all revolving around the number of people that have enough understanding to run the tests. My company has three plus one consultant that can run the majority of the tests, it is preferable to have employees sign off on everything so the consultant is out, and one of the three has the understanding to run the tests, but not the personality type to see it through. That leaves the two engineers, one of which is on vacation this week, so that leaves me for now. MD&DI sums up the who should do the bench testing very well.

The first problem is the protocol, which must be signed off before the test begins, the problem here is that no one besides the engineer authors are likely to really understand what is going on. This means no problems will be caught until the engineer testers try it for real. Sure, we've tested it some previously, but when everything is recorded things change. I wrote a protocol and discovered I couldn't hold a negative pressure I thought I could so had to change it up a bit. This means rewriting and walking around getting signatures to get it approved before I can start again. This is not much of a problem, unless it is after 3:30pm and QA has gone home for the day. Then I'm forced to wait around until they come in at 9 the next day. I have argued that by having my signature on it that the protocol has therefore been predefined and good to go, but I haven't gained much ground with that.

The next problem is that these tests take time, we are shooting for 24 hours of use. I rallied around testing for 26 hours but my boss vetoed that saying 1.5 times is standard, meaning 36 hour tests and every other day I have to come in at an awkward time (do not worry, I am getting my revenge- see below). I am amazed my wife hasn't accused me of cheating on her yet with the late night stops by work. The 1.5 times the maximum limit you're shooting for is a good rule of thumb, and appropriate here, but it doesn't work for everything, like negative pressures.

The last of my whining centers around the sample sizes that will not be high enough to make everyone happy. With limited product and limited resources, running a dozen 36 hour tests could take a month. Unless you are going to manufacture, sterilize, and shipping simulate a batch of samples yourself in the next week, complaining about sample size doesn't accomplish much. Do a reasonable job and if the FDA picks on it the most likely thing that will happen is they'll ask for more testing.

I mentioned in my previous post that the deadline slipped (still not my fault), this has given me time to come up with some additional bench testing to put in motion. I say put in motion because I was so confident I'd meet my part of the original 510k deadline that I planned a two week Hawaii trip starting one day before the deadline. Now all the loose ends will have to be tied up by my boss and the other engineer, I sorta feel guilty now, but about 20 minutes after landing it will be forgotten. I give the extra testing a 40% chance of not being done when I get back. I have to say though that the last year has been a blast and if you're an engineer with a good work ethic that can tolerate the risk of working for a smaller company then go for it.