Recognizing the fast pace of advancement in software development, FDA is searching for the best way to regulate higher-risk medical software products. The tricky part of oversight comes in trying ensure safety while maintaining a rapid pace of innovation.
"Can we re-look at the paradigm and see--what is the best way to review and have oversight of software? Because it's not physical. It changes fast. It iterates faster than any other product we know in the physical world," said Bakul Patel, associate director for digital health at FDA, during the MD&M East Conference this week in New York City.
Patel appealed to the audience members to tell FDA how the quality system regulations work for them as software developers. Many developers use agile software development, a methodology that is characterized by quick turnaround, constant improvement, and fast adaptability. Of course, this continuous change means regulation is even more challenging. "One of the problems is, there are less discrete steps in software development than exist in a physical device," Patel said.
Start planning your fall schedule now. Register for the MD&M Minneapolis Conference, September 21-22.
While this week's brief discussion didn't yield any satisfactory conclusions, Patel has addressed some of these questions as chair of the International Medical Device Regulators Forum (IMDRF) working group on Software as a Medical Device (SaMD). SaMD is different from software in a medical device. In 2014, the SaMD working group released a framework that would classify software into one of four categories, based on the seriousness of the healthcare situation or condition and the level of impact the information provided is expected to have on a healthcare decision. Software that aims to treat or diagnose a critical healthcare condition would be in the highest impact category, Category IV. According to the framework document, an example of a Category IV SaMD would be diagnostic image analysis used to decide treatment for acute stroke. The lowest-impact category I would include a SaMD that measures and send metrics like heart rate, distance, and walking speed for a cardiac rehab patient to a clinician. An IMDRF document released in 2015 discusses quality management system considerations for SaMD, including risks related to users, the device, the application, security, and use environment.
In the past, FDA has tackled the question of regulating medical apps, taking a light touch that narrowed the scope of its oversight. As Patel pointed out, most products that offer a benefit without endangering the patient, such as simple communication tools, tracking health information, or features that automate parts of a clinician's job, are products for which FDA practices enforcement discretion and does not regulate.
Still, there can be some points of confusion. Discussion at the conference session this week included digital calculators used to determine risk scores or measurements. Many of these would not be regulated by FDA because they serve as tools to double-check the clinician's calculation. Yet insulin dose digital calculators would be covered by FDA because these are used at home by patients, not clinicians, to make treatment decisions.
Morgan Reed, executive director of ACT-The App Association, which represents more than 5000 app makers and software companies, concluded the session by urging the audience members to send FDA and The App Association ideas, articles, documents that might help the agency develop its approach. It's not likely to be a quick or easy process. "It's hard when the FDA says to us, 'I don't know, you tell us.' That's a very hard thing when it comes to meeting with your investors and the rest of your business unit that you got an 'I don't know,'" said Reed.
[Image courtesy of STUART MILES/FREEDIGITALPHOTOS.NET]