Ensuring Smooth Regulatory Submissions in Software for Medical Devices

Many companies struggle to understand regulatory expectations of their submissions which can lead to long and costly delays. We spoke to Arnab Ray, Senior Research Scientist at the Franuhofer Center who gave us his key points to ensuring a smooth regulatory submission process

Gerald Clarke:           Arnab, could you give us a little bit of history of your background in the field?

Arnab Ray:     Yes, I'm a PhD in Computer Science with specialisation in software engineering. The reason why I'm interested in medical device software is, firstly, a tie to my larger interest in mission critical systems and mathematical reasoning of software that goes into things that can't fail, and as we can all agree to, medical devices can't fail. They shouldn't fail, but they do nonetheless. In 2008, I obtained funding from the National Science Foundation to do research at the Food and Drug Administration, which is the primary regulatory body of the United States of America. With extensions, it was a three-year project to look at software engineering practices for tomorrow that ensure safety in a mathematical way. As part of this project, I got insight into the regulatory process, why different device manufacturers fail, of course with the focus on software because I am a software engineer; why is software a problem? Later on, towards the end of this project, security became a big, important problem because normally regulators look for safety and efficacy of medical devices. Now they suddenly saw wait, there's a third thing that we need to start looking at because it adversely affects the other two, which are safety and efficacy and their security. That's when I started going into that part of the pie.

Clarke:           What do you see as the major challenges for those operating in this field?

Ray:                With respect to software, it's the sheer complexity of the software that's being put on devices. We used to think of medical devices as primarily embedded systems in a fairly simple way, that there were these control algorithms which sent things from the human being, did some computation and then did something to the human being. It's normally the model of a medical device. But this has changed; it's not just the control part of a medical device. It's a huge IT infrastructure almost around a medical device nowadays. For instance, a medical device: originally, they were all machines. Now they are expected to be nodes on a network and that network can be connected a larger hospital network; it can be connected to other devices. The whole paradigm of a medical device has changed, so if somebody came from the past – like 30 years ago – in a time machine and saw what medical devices are today it would be very difficult to identify what he sees today as a medical device. The reason for that is the sheer complexity and the amount of software that's put on medical devices and increase has blown up, and that has become a problem, as in a problem for the manufacturers because they now have to make a case to the FDA that their software is safe and that the device is still effective. The regulatory burden on manufacturers has increased because the software has become more complex, but that's just what the market is demanding. It's going to get even worse or better, depending on your point of view, as we go along.

[inlinead]

Clarke:           With regard to regulatory submissions, what are the difficulties that companies generally encounter?

Ray:                One of the biggest problems that I have seen with companies is that they find it difficult to link their safety requirements to their test cases. What they do is in a regulatory submission they'll have these are our safety requirements. All right, we get that. Then there's another document, which says these are our tests cases; so if I give one, two, three as input, I get four as an output. Now I've been amazed to see how little there is a connection between those safety requirements and these steps. It's a huge conceptual leap to go from those safety requirements to these tests and then claim that if the face that my image machine passes these tests is proof that I've satisfied the safety requirements. There is a huge, huge conceptual leap and that conceptual leap is not traced through in many submissions. Many regulators often find this huge disconnect. That's one problem.

Another problem often is purely the number of hazards that you have considered, so if you're a medical device manufacturer making a widget X you come up with a list of hazards, which are the things you handle, and many of the problems happen in that there are hazards that you should have considered, which are excluded. What do you mean by you should have considered that you have excluded, because you could say well, hazards sound like things which can happen which I don't know of? If you have a competing product which has already handled those hazards, and you're not handling the hazards, then that's one of the reasons why you might get rapped on your knuckles. As an example, if you have patient-controlled analgesic pumps, and you don't have a drug library inside it; drug libraries were not considered to be standard safety features a few years ago, but now they're considered to be standard safety features. That's why medical device manufacturers need to take a good luck at what everybody else is doing and what the safety standard currently in the industry is, and they should at least match, if not surpass it.

Clarke:           What are the key points to ensure an organised and successful submission process?

Ray:                The key point is get expert help; that's the first thing. Either have it in-house or get it from outside. Many people think that oh well; I can just put the documents together that they had for development and just give it to the FDA. No, that's not exactly accurate. Many companies spent years – and I have worked with companies which have spent the greater part of ten years – waiting to go through the FDA regulatory process. The biggest impediment often has been software. I have heard of cases where people get a pre-market approval for their software, but since it took five years for them to get the pre-market approval, actually the software that they were building has totally changed, because after all, who keeps the software stationary for five years. Once they put the new software and tell the FDA look, we have new software, then the entire thing's clock is almost set back. The short answer is get expert help, manage the process of your software going through the regulatory pipeline. Now big companies do this great; they know this is the problem. It's sometimes the small and the medium-sized companies which creep on this.

Clarke:           Thank you, Arnab, for sharing your thoughts and your insights with us today. We look forward to hearing more from you at the Software Design for Medical Devices event. If you would like to find out more about this topic and the Software Design for Medical Devices Europe conference in January 27-30 in Munich, Germany, visit us at www.sdmdeurope.com.

Please note that we do all we can to ensure accuracy within the translation to word of audio interviews but that errors may still understandably occur in some cases. If you believe that a serious inaccuracy has been made within the text, please contact +44 (0) 207 368 9482 or email gerald.clarke@iqpc.co.uk