Patching Microsoft Windows on medical devices

Law Firm IT has an interesting post on installing the latest Windows patches on medical devices, including this:

"...because the machines were running an unpatched version of Microsoft's operating system used in embedded devices they were vulnerable.

Normally, the solution would be simply to install a patch, which Microsoft released in October. But the device manufacturer said rules from the U.S. Food and Drug Administration required that a 90-day notice be given before the machines could be patched."

I'm not sure if that is completely correct about a required 90 day notice to the FDA before patching Windows. I'll leave that to a regulatory expert.

I do know that any changes to Windows and the medical device software has to be revalidated, at least the potentially affected parts anyway. The revalidation is obviously going to take time and effort and the rewards are often low, especially if you label your device to not be connected to the internet. You want your software guys putting in new features, not screwing around with Windows compatibility for people who are using the device off label. Additionally, the Windows patch needs to be installed, no small feat for a device that is not supposed to be connected to the internet. All of this time adds up and the bottom line is you're never going to be a step ahead of software virii on a medical device, which is why they almost all say do not connect them to the internet.

That being said, Windows with the help of one of several off the shelf software programs, such as Clean Slate, Rollback Rx, and Deep Freeze, can be fairly easily configured so that the chances of a virus are minimized, meaning that you wouldn't have to update Windows with every patch. In fact, this seems like a halfway decent mitigation (along with the aforementioned labeling) to your "device connected to the internet" hazard as part of your risk management.

(Picture by Alexander Fediachov)

510(k) response received

A while back we received our 510(k) response, about 60 days after the submission, and if a 10 was as good as could reasonably be expected we ended up with a solid 8, so we're all pretty happy. We had one hardware comment, a couple labeling comments, around six software comments and a couple non-software V&V testing comments. Nothing actually that hard to respond to or that left us scratching our heads, "How do we do that!?". If we kept key parts within the company we could probably respond in the 30 days given.

I'm trying to think of something useful I could pass on, but most of it boils down to little things we forgot to include in the submission even though they are clearly documented on the FDA website. The FDA obviously spent a lot of time reading the Software V&V and requested some more typical condition testing instead of the worse case testing that we focused on. Everything they requested was very reasonable though. Same with the non-software V&V testing, out of the 20 or so reports the FDA only commented on two, I missed a standard and tested to the wrong limit, and for one test they wanted more typical condition testing. They probably can't use the words "brilliantly done" in the letter, but they did use the phrase "generally acceptable" which is good enough I think.

Anyway, it is good to receive a response and now we have something to focus on. We'll get the work done ASAP and hopefully the next letter we get from the FDA is an approval.

510(k) filed

Our company finally managed to file our 510(k) with the FDA last week and of course I have some random thoughts about the whole thing, I also have planned a big toot my own horn post later. It took approximately two years and $10 million (very approximately on that number) from concept to filing of a disposable and the (non-disposable) electronic controller "me too" device (filed as one 510(k)). There are still some kinks (mostly software) to work out before we are ready for clinicals- but we are pretty close.

In our case, I think it may have been possible to cut costs by 30% or so, but hindsight is 20/20. If we stuck to the long term vision, that could have saved us money. For example, the software guy was rushed to get a working demo up and going early on to show off to an interested third party, then had to go back and reprogram a lot from scratch as the demo didn't have the proper coding structure. Additionally, better management of some consultants could have saved us money and time. I don't think it is insulting to have a consultant doing an hourly or four hourly log sheet and then checking it every now and then against work done, at least for new consultants. Asking them to do mundane things that an assistant should be doing is also not the greatest idea, of course they are eager to do it, they are making $80 an hour + expenses to drive across town and pick up that stuff.

The software turned out to be the hold up and better planning could have saved us a good amount of time. Having an engineer working on just software issues would have helped, having weekly meetings with everyone involved didn't always help because the software guy wasn't able to prioritize correctly. The basic functionality must come first, the screen layouts and some other minor things are just too tempting for some people not to lay off of.

The last device I worked on the disposables packaging was a major problem, and I'm happy to say we managed to avoid most of that this time. The packaging is hard to do (IMO) because you really can't simulate EtO sterilization unless you actually EtO sterilize something and that will cost you probably at least $10,000 and a month and a half. We did the best we could, running the shipping simulation and the sterilization (time, temp, humidity) conditions beforehand, but I still notice some different effects when compared to the actual sterilization.

Getting FDA approval is the next step, but I'm not overly worried about it, the FDA is generally not unreasonable (in my experience) and honestly, the most likely outcome, one set of questions then they require clinical trials before final approval, would benefit the company in a number of ways. I think the hardest part will be after that, selling these things, doctors and nurses are keen on new devices and competition in general, but getting them to actually buy from the new guys is a different story.

Finally sorta done

We finally managed to "sorta" finish enough of the 510(k) to send it to the regulatory consultant. If we hurry it will only be submitted 2 months behind the original schedule, I have a big horn tooting post planned for then. By sorta finished I mean I need to slip a few more details into the software section before its final and the poor VP is double checking my traceability analysis line by line and he'll probably have a few changes. That is the reward he gets for also being the management quality rep.

You can drive yourself nuts attempting to second guess what the FDA wants as far as a software validation, it is almost purely a judgment call. I could easily write another few months software testing into there, would it be useful testing? 99% of it probably not, but it takes that 99% to find the 1% where there may be an issue. Is it worth it to spend half a day rigging up a test to show that if the hard drive is full the software can deal with it? At least 20 gb of free space, and the files are less than 100 kb, if someone fills that up we sold them tens of millions of dollars of disposables- if only! Much of this has to come down to trust on the FDA's part, because outside of having 2 guys test the machine for 6 months (in my experience they don't ask to even see the machine), it is difficult for them to judge the quality.

It was getting a little tense at work for a while, hopefully with the 510(k) out of our hands we can get back to normal. There is still a lot of work to be done, a couple items in the 510(k) we told the FDA we'd finish before clinical use, but the bulk of the work has moved from product development work to mostly manufacturing fine tuning. Everything needs fixtures and some bugs in the process need worked out to get the product consistency we need. If that wasn't enough we're also moving the company, which is scheduled to be a one month delay, but I foresee a three month delay in progress.

PS My wife has assured me that the new header matches the rest of the blog, green and brown matches, who knew?

Software Design Specification Writing

I spent the last week and today (minus time out for inane tasks that get us nowhere, focus people!) writing the software design specifications (SDS) . Honestly, I could probably spend another week on it. The SDS is key part of FDA 510(k) submission software section and verification and validation (V&V) and I suspect the software section is the section the FDA will rightly focus on. Unfortunately, the guy who wrote the software has a hard time transferring his thoughts from code into English, he wrote a really rough draft then I had to take over once we started looking at it. It is difficult to split the SDS and software V&V into parts that more than one person can work on, which means I get bugged a lot about progress by people who don't understand how one document could take a whole entire week to finish when we had a draft last week, then have other documents to write after that that may take even longer.

Before I left on vacation in December the V&V was scheduled to be done the next week- no one followed up on it and since only one person can really work on it at a time if that person is bugged to do other things, no progress is being made. I posted about getting a draft V&V before. How did it look? Brutal. Now it looks like I'm going to spend next week writing most of it. The software guy thought he should write the V&V first before the SDS and then we could work on the V&V while he wrote the SDS, but that just turned into a big mess. The company is kind of schizophrenic lately and can't seem to focus properly, which is why they had me do the SDS this week instead of two weeks ago right when I got back. If the software documentation is holding you back, every minute engineers aren't working on software documentation is delaying the submission, just keep that in mind before talking to them about anything at all, really.

Anyway, I think ideally you take the software design requirements, add to it so it becomes the SDS, then take the SDS and add the V&V steps, that way your traceability is covered without sitting around cross referencing documents for two days.