Opening up the market; FDA and the gift of MDDTs
FDA recently updated its guidance on submitting a Medical Device Development Tool (MDDT) for approval by FDA. The original guidance was published in 2017, but it was barely used. Now, I foresee an explosion in MDDTs related to building trustworthy software.
Innovation in a highly regulated industry is more risky than other industries. Not only does the innovation need to work and customers like it, but the regulator also has to understand it to clear it for market. Inherently, when we do something new we need new evidence to support it.
Currently, much of the “new” stuff in medtech is coming from software and automation. But medtech software updates are generally slow. Very slow. Sometimes less than once-a-year slow. This seems ridiculous in comparison to the technologies we are accustomed to. Consumer tech can receive updates and upgrades to software on an almost continuous basis. I have heard stories of commercial software deployment pipelines completed in less than 12 minutes.
Why is medtech software so slow? The delay in producing updates is often rooted in verification and validation processes, regulatory and quality processes, or other procedures that require specific human interventions and judgment. Humans are the slowest link.
Cybersecurity Example: Human Judgment
For example, some medtech quality systems require a vulnerability management scan and security risk assessment for each release. In theory, this makes sense; a new vulnerability in medical device software could pose a risk to patients. The vulnerability scan may be automatable, but as written, security risk assessment is manual and often requires multiple different humans to complete (i.e., the software engineer and the cybersecurity expert at least) and review (e.g., project management, quality). I have seen this process require months to complete.
Enter, automation. We can automate a lot of these processes, especially repetitive computational processes like software vulnerability assessments. However, we have to establish a reliable paradigm to ensure that the automation is trustworthy. And if we invest in that automation, we need to make sure it's a wise investment. We need to know that FDA and other regulators will accept the response, and we need to be able to use it across multiple products.
Enter, MDDTs. Imagine a medical device vulnerability assessment tool that can automate 90% of the human effort for vulnerability evaluations across a wide variety of product types AND is pre-approved by the FDA as a suitable means of meeting postmarket management requirements. The speed of releases would increase drastically.
Diabetes Example: Simulated Clinical Evidence
What if the hold-up for software releases isn’t the limitation of human judgment, but the inability to run a trial to test a new algorithm’s effectiveness on clinical outcomes? Once a device or system like automated insulin dosing is approved, we want to keep updating the algorithms to get the best possible outcomes for patients. But we can train algorithms much faster than we can run clinical trials (not to mention the expense).
Enter patient digital twins and simulated clinical results. A simulation environment used to train algorithms can also be established to evaluate those algorithms. In fact, it is a basic and standard practice to train AI and machine-learned models on a “training” dataset and test them on a hold-out set of remaining data. But those data get “stale” quickly; they can’t be continuously reused to train new models lest the models become overfit.
A simulation environment developed to mimic the real world can provide additional data and solve some of the problems. But regulators like FDA may be unfamiliar with the validity of simulated evidence for diabetes outcomes, and therefore using a sim in development is a source of regulatory risk (for startups, regulatory risk is tantamount to existential risk).
Imagine a simulation tool was available to evaluate new automated insulin delivery algorithms premarket so that new entrants could always have a fresh dataset on which to train their models. Large manufacturers could even outsource portions of algorithm development based on competition (like Kaggle).
MDDTs as a means to create a market for reliable medtech development
None of this would be powerful without assurance that it’ll be cleared by FDA. The MDDT program affords the industry the opportunity to pre-certify clearance - and therefore reduce R&D risk - for more novel and sorely needed approaches.
Effectively, this program could establish and grow the secondary industry of medical device development vendors, which is good for innovation.
Thanks, FDA, for updating the guidance for Medical Device Development Tools.
~Shannon Lantzy, the Optimistic Optimizer
留言