Bradley Merrill Thompson, RAC
Medical Device, Digital Health and Combination Product Regulatory Attorney
September 2015
< 1 min reading time
In this paper, I outline in detail the structural biases against anything new in the medical technology realm, including novel software. I wholeheartedly support FDA regulation of risky technology, but the law places disproportionately large regulatory obstacles in the path of low risk, new technology simply because it is new. That is not in the best interest of patients. We cannot fear the new. How the FDA process is biased against new technologyLet’s say no one had ever invented the tongue depressor, but this year, in a flash of inspiration, I came up with the idea. Indeed, let’s say there’s nothing else like it. To bring the first tongue depressor to market, it’s quite likely I would have… source: https://www.linkedin.com/groups/78665/78665-6048051316993900544 Marked as spam
|
Meet your next client here. Join our medical devices group community.
Private answer
Srinagesh Koushik PhD RAC
Hi Bradley,
As always wonderful post. FDA should be aware the problem Automatic Class III designation does to development, and so I agree with you CDS and similar software will suffer in the short run because of lack of resources. Keep up the good work hope to run in to you again at a mHealth workshop soon. Marked as spam
|
|
Private answer
Bradley Merrill Thompson, RAC
Michael, I agree with you wholeheartedly that industry needs to partner with FDA to find solutions. Certainly criticizing without constructive suggestions is totally useless. At the same time, I think everyone needs to be ready to think outside the box. I'm not convinced that merely tinkering with the de novo process will yield the desired improvements. I think for low risk software, we may need a different system. That different system could be FDA publishing some new classifications for low risk CDS and other clinical software. To do so, the agency and industry would need to work together collaboratively to identify some new classifications that the agency could publish. But as I said in my post, that takes money and at least for now FDA seems to be saying that it doesn't have any for this purpose. If FDA continues to say that it cannot facilitate the classification process itself, then perhaps Congress could solve the problem by either coming up with some statutory classifications or by flipping the presumption that certain categories of low risk software are automatically class one, with the potential to be up classified by FDA. Frankly I can think of dozens of solutions if the stakeholders are just willing to work together toward a common solution.
Marked as spam
|
|
Private answer
Robert Christensen
Yes, I can attest to some of foolish decisions made by some of the leaders in the FDA as I brought forward an implant for that I had innovated some forty years earlier. It should have been approved like other pre-amendment, grandfathered, orthopedic type of implants. It had never any problems when placed in thousands of patients over that 40 years, and yet the FDA put us through a multimillion dollar approval process.
Marked as spam
|
|
Private answer
Srinagesh Koushik PhD RAC
To Michael's comment, I have experience dealing with devices, diagnostics and mobile medical apps and softwares. The issue Bradley raises is absolutely valid. The de novo process works well with medical devices and diagnostics because there is frequently a need for clinical data to demonstrate safety and effectiveness. De novo has been around for more than 10 years, the major interest in the process started peaking after FDASIA in 2012 and more devices and diagnostics have been cleared through this pathway recently.
Bradley's point was you cannot use the same criteria to deal with medical software and I completely agree with his assessment. FDA had taken strides towards addressing these issues by punting ( enforcement discretion) and to requesting feedback through pre sub process, that works for devices and diagnostics developmental timelines, but fails with software timelines. Marked as spam
|
|
Private answer
Julie Omohundro
Srinagesh, could you clarify what problem(s) Automatic Class III designation causes for development and also how software deadlines are different from device and diagnostic deadlines?
Marked as spam
|
|
Private answer
Srinagesh Koushik PhD RAC
Julie,
I am not talking about simple devices that do not require any electricity or software that needs to be written to drive them. You could potentially design a bandage that can be brought to market in short term, say in less than a year provided you can complete the biocompatibility and chemical and physical testing in that time frame. Devices that require software on the other hand require software and hard ware to work well together and go through multiple iterations of development taking months to years. Stand alone software development does not involve engineering the prototypes and multiple iterations of bug fixes that typically occur with moving parts. Software code writers could potentially write code, especially for apps that are can be built in a month and put on app stores quickly. I was also referring to Bradley's point in the paper which is if your app deserves to be classified as a class III then absolutely de novo is great but if it can be shown by risk analysis that it is a not high risk then de novo path that has a mandatory 120 day review time once submitted without including the presub time is too long a delay. Hope that helps. Shree Marked as spam
|
|
Private answer
Julie Omohundro
Srinagesh, thanks for the additional and informative information.
I understand that you are saying that software developers could push out new software a lot faster if they didn't have to go through FDA review. That is true of all devices. However, I understand that you are also saying that, proportionally speaking, the FDA review time is a lot greater, compared to development time, for software apps, which can be developed more quickly than devices involving hardware. Now my question is, what is the problem with that? It's not a competitive problem if all software is subject to the same delays. It does not add much cost either. There is no fee for either a pre-sub meeting or for a De novo petition. The only additional cost is the time required to compile the submission, which should be pretty straightforward if the device is simple and low-risk. I'm not sure if I got answer to the question of why Automatic Class III designation is a problem for development. Your answer focuses on the requirements of the De novo process, not the Automatic Class III designation. Perhaps when you said that an Automatic Class III designation was a problem for development, what you meant was that, if you chose to pursue a De novo to get a lower classification designation, that process was a problem. In that case, I did get an answer. Just not sure if that's what you meant, or if you were referring specifically to a problem with the designation itself. I will also quibble with a couple of your statements. The De novo process is not great for an app (or any other device) that deserves to be Class III. It is pointless for an app (or any other device) that deserves to be Class III. The whole point of the De novo is to present data to FDA to support Class I or II, rather than Class III. If the app (or other device) deserves to be Class III, then a De novo petition is no improvement over going straight to PMA, and possibly less efficient than going straight to PMA. The "mandatory" 120-day review period for a De novo is the maximum amount of time FDA is allowed to spend on its part of the review. It is not mandatory that FDA take this long to review a De novo, although I grant you that it can seem that way sometimes. Marked as spam
|
|
Private answer
Julie Omohundro
Michael, do you have any links that provide details (e.g, articles in the press, not official documents) on FDA's efforts to establish a Class IIb, Congress shooting it down, and industry applying pressure? I was swamped at the time and missed that particular little drama.
Marked as spam
|
|
Private answer
Srinagesh Koushik PhD RAC
Julie,
For the record I love the de novo. I think is is absolutely fantastic that FDA recognizes its usefulness and has been actively pushing it. The issue that you raise is equivalent to saying that every dinner that is made at home should be like thanksgiving dinner. If such a regulation exists no one will cook. One size fits all regulations does not work with all software apps. For instance, provides daily updates of blood glucose or some other chronic bio marker to a physician may not affect patient outcomes but may have to go through clinical trials to get cleared or approved. However, a doctor may ask his patients to call in their results which is considered practice of medicine and not regulated. The example I have provided may not be the best, Bradley's article gives better examples of software that went through the process as it stands and spent years in FDA world. However, I appreciate your opinion and agree with it from a medical device or diagnostic perspective. Shree Marked as spam
|
|
Private answer
Julie Omohundro
Thanks, Michael. Srinagesh, time well tell on all of this, but the last phrase I'd use to describe the De novo process is OSFA. On the contrary, I think it's inherent flexibility is its strongest asset.
Marked as spam
|
|
Private answer
Julie Omohundro
Michael, thanks. I didn't realize the IIb was proposed in that guidance, though of course that makes sense. I was mostly wondering who played the role of "industry" in the IIb drama. But if it was part of the 2011 guidance, then I know the answer to that question.
Marked as spam
|
|
|
|
Private answer
Michael Lehmicke
Julie,
The proposal for a class IIb was one part of a series of recommendations to update the 510k process which were proposed by an FDA task force a few years back. The attached link provides a concise overview. http://www.raps.org/regulatoryDetail.aspx?id=9982 Also you can search the FDA website for UCM220783 and related documents. -Mike Marked as spam
|
|
Private answer
Jerry Robinson
We can't fix the FDA - at least immediately...
So the "wise question" - becomes something different... How can we dance around the "bear" - and yet "still reach the finish line?" the US is 4.6% of the world's population. With Amazon and Alibaba, there is a precision, international shipping and delivery service..... With some persuasion - there should be a higher control level of delivery... So.. Can you ship your NEW medical, de novo, device or app OUTSIDE THE US.... gather information and use that information to fit the FDA submission - clinical trials issue - and still make a living doing this? If there a brick wall stopping you in the US - and it takes YEARS to get something approved.... then GO ELSEWHERE and think Global... Simple from that standpoint.. Think Global - Act Local... and Local can be a lot of different places.... Great Article.. Marked as spam
|
|
Private answer
Julie Omohundro
Jerry, I think global is an excellent way to go. At the same time, those who know how to dance with the bear, instead of fight with it, will almost always be the first ones across the finish line. (For startups, they will often be the only ones who finish the race.) And sometimes, the best way to dance with the bear is to first court it with some tasty sweets you picked up in a nice little shop overseas. :)
Marked as spam
|
|
Private answer
Jerry Robinson
Good....
A multi thread solution.... So... defining a set of success stories on combined International and FDA compatible rollouts would be a good thing.. Playing the game by US only approach looks to be a serious risk - and serious sink of time. If one were to have 5 example of "new" type cell phone apps/devices - and how they were rolled out.. then that would help all involved.. Cell phone apps/devices are not just one or two - here and there... think of it as a stampede of different soltuions.. certainly hundreds.. probably thousands... all in parallel - all in similar time frames... Some places in the US - these solutions will work.. others - they won't ... it will "appear" to be chaotic - but of course, isn't... When a successful solution type or method shows up, then a HORDE of companies will "copy" and "emulate".... the disruptive innovation effect would suggest that most such apps/start ups will "die" - from a real variety of reasons.... Traditional Medical providers almost certainly will not play in this chaotic space... they would keep an "eye out" and pick up the most appropriate and successful ones in their business space... Getting to a successful spot - with mHealth devices - means overcoming more than just the FDA documentation hurdle... how to do it is the magic part... Marked as spam
|
|
Private answer
Julie Omohundro
"Stand alone software development does not involve engineering the prototypes and multiple iterations of bug fixes that typically occur with moving parts. Software code writers could potentially write code, especially for apps that are can be built in a month and put on app stores quickly. I was also referring to Bradley's point in the paper which is if your app deserves to be classified as a class III then absolutely de novo is great but if it can be shown by risk analysis that it is a not high risk then de novo path that has a mandatory 120 day review time once submitted without including the presub time is too long a delay."
Srinagesh, the De novo path is intended only for devices that are 1) novel (without a predicate) and 2) do NOT "deserve" Class III. The De novo process was revised by Congress specifically to provide a path for these devices that is less burdensome than the PMA path for a Class III device. The rationale as to WHY your device is of should be regulated as a Class I or II device, rather than as a Class III device, is at the heart of a De novo petition. Submitting a De novo petition that explains why a device "deserves" Class III is not "fine" or "not fine'; it just would not make any sense. I am not clear on the link between "apps can be built in a month and put on app stores quickly" and "too long a delay." You seem to be arguing that the time required for FDA to clear or approve a device should somehow be tied to the amount of time it takes to develop it. If this is what you are saying, why should that be the case? It is not true of hardware devices, some of which can be developed fairly quickly and some of which can take a very long time. Nonetheless, the regulatory timeframes for a hardware device reflect the classification (i.e., risk) of the device, not the amount of time it took to develop it. I don't see any reason the regulatory timeframes should reflect the amount of time it takes to develop a software device, either. Beyond that, I have the same question I always have when someone says that "X is too anything": Too long for what? Marked as spam
|