In a quest to help medical device makers and software developers better understand when to notify the Food and Drug Administration regarding changes and modifications to their tools, the FDA in early August released draft recommendations, as well as a guidance document regarding software updates.
The agency states the documents are intended to ensure consumer safety and technology effectiveness, as well as help device and software makers avoid unnecessary agency evaluation. The guidance also illustrates that the agency does not want to be "Big Brother" on health and wellness device development. For example, it won’t require evaluation of low-risk wellness devices, which includes wearables.
Brad Thompson (pictured right), a health attorney at Epstein, Becker and Green, tells FierceMobileHealthcare that the guidances are very useful and provide some long-overdue clarity.
"Many folks in the mHealth market have been struggling in a sea of ambiguity for many years, but the Mobile Medical App Guidance and this guidance on software modifications provide a much clearer picture," he says.
Thompson adds that he hopes the FDA is "open-minded" when reviewing comments. The devil is in the details, Thompson notes, and he expects that the agency will receive quite a few useful and insightful comments.
In this interview, Thompson also discusses the impact of the recommendations on mHealth tool and software developers.
FierceMobileHealthcare: What led the FDA to publish these documents?
Brad Thompson: These guidances are long overdue. The FDA first tried to update the 1997 guidance on device modifications in 2011. But when it did, its draft met a firestorm of resistance from industry, amid concerns that the document would cause a significant increase in the number of product changes that trigger the need for a new 510(k). Industry made its case to Congress, and the 2012 FDASIA legislation required FDA to revoke the 2011 draft and start over.
Indeed, Congress required the agency to consult Congress in producing the new draft. In 2013, there was a public hearing held on the topic. So the FDA has been working steadily toward these new drafts for quite some time.
FMH: Will these new documents have an impact on digital health tool developers?
Thompson: Much of the guidance speaks at a very high level because it covers such an extraordinary range of software. And indeed, there is quite a bit of imprecision left in the guidance. Just search for the word "likely". You will see it often used to qualify statements of whether a 510(k) is required. Look for example on page 15, under section 6, line 492.
Later on that page, starting on line 513, they acknowledge a specific example of where there is uncertainty. I am particularly concerned about this section because many different types of software changes could potentially affect clinical functionality. That is a very sweeping standard, and my concern is that it might be interpreted to sweep many software modifications into the 510(k) net.
To be clear, I would not want them to simply strike out the word “likely." I'm not in favor of certainty for the sake of certainty. I realize, in many instances, the specific facts matter very much. My only point is, this guidance is intended to clarify the requirements for an industry that is probably not unified in its approach to making these decisions, and is meant to give fair warning to industry before enforcement of this legal requirement. But when the government has this much trouble stating specifically what is required, it suggests that the government should not be too punishing when companies make a decision in good faith with which the agency disagrees.
In many ways, the real meat of the guidance is in the appendix that includes the examples. The general language in the first part of the document really doesn't add a whole lot of clarity until we see how the agency applies those general statements in more specific situations. That said, perhaps not surprisingly, the FDA has picked mostly easy cases for its examples.
FMH: What will be the impact to mHealth software developers?
Thompson: At a policy level, one of the very difficult challenges of writing a guidance on when a 510(k) is required for modifications is the unintended consequence of discouraging product improvements. For years, medical device manufacturers have struggled with this, because if FDA makes it burdensome to make even small improvements to medical devices, companies tend to shy away from making those improvements or at least delay those improvements to make them all at once as a part of a single submission.
In an area such as software, change is constant. Software developers are constantly trying to improve functionality. Anything that discourages such improvements runs the risk of hurting patients in the long run. FDA must offer some leniency to manufacturers to continuously improve their products without onerous burdens.
Editor's Note: This interview has been edited for clarity and length.