By admin 
For more than three decades, the daily reality of my life has been defined by the meticulous management of type 1 diabetes. This chronic autoimmune condition requires a constant, high-stakes balancing act: monitoring blood glucose levels and administering precise doses of insulin to avoid the immediate dangers of hypoglycemia and the long-term, devastating complications of hyperglycemia. For years, I relied on the cutting edge of regulated medical technology, utilizing a continuous glucose monitor (CGM) tethered to an insulin pump. Every five years, like clockwork, I would transition to the newest generation of hardware—devices meticulously vetted by the Food and Drug Administration (FDA) and dutifully covered by my health insurance. These devices were marvels of engineering, yet they were not perfect. Despite the "upgrades," my glucose control began a slow, frustrating decline. The algorithms meant to automate my care were conservative by design, optimized for the "average" patient rather than the idiosyncratic realities of my specific physiology.
The turning point came when my physician, recognizing the limitations of the current commercial landscape, suggested I look into open-source software. This was a move into the "DIY" world of diabetes management, a community-driven movement often tagged with the hashtag #WeAreNotWaiting. I began using a new code—software developed not by a multi-billion-dollar corporation, but by a collective of patients, parents, and engineers who were dissatisfied with the rigid, FDA-regulated applications provided by manufacturers. This open-source system, which runs directly on my iPhone, was a revelation. By fine-tuning insulin delivery in real-time based on granular data that commercial systems are often too cautious to act upon, it allowed me to achieve glycemic targets that had previously been out of reach. I felt better, my data improved, and the software was entirely free.
However, as a health economist and the founding director of the USC Schaeffer Institute for Public Policy and Government Service, I am acutely aware that my personal success story sits atop a precarious regulatory foundation. Using this software is, in many ways, a calculated gamble. This technology exists entirely outside the traditional oversight of the FDA. In the United States, the FDA regulates medical software as a "device." This classification is intended to ensure that any tool making clinical decisions is safe, effective, and free from the "bugs" that can plague consumer software. But the framework the agency uses is increasingly at odds with the nature of modern software development. The FDA’s review process is thorough, but it is also inherently slow and expensive—a relic of an era when medical devices were physical objects like pacemakers or hip implants, not lines of code that can be updated in an afternoon.
The current regulatory bottleneck is reminiscent of the famous "I Love Lucy" episode where Lucy and Ethel are overwhelmed by a speeding conveyor belt at a chocolate factory. The pace of software innovation—fueled by rapid iteration, user feedback, and now, artificial intelligence—is the conveyor belt, and the FDA reviewers are the workers struggling to keep up. The speed of the product line has outmatched the capacity of the regulators. Consequently, a system designed to protect patients is inadvertently becoming an impediment to the very innovation that could save or improve their lives.
To understand how we reached this impasse, one must look at the statutory history of the FDA. The agency operates largely under a 50-year-old statute, the Medical Device Amendments of 1976. While Congress has updated these laws over time, the fundamental architecture remains rooted in a "pre-market approval" mindset designed for hardware. When a company develops a physical heart valve, it stays the same once it is implanted. Software, conversely, is never "finished." It requires constant patches, security updates, and algorithmic refinements. Under the current system, significant updates to a regulated medical app can trigger a requirement for a new regulatory submission, a process that can take months or even years. This creates a perverse incentive for manufacturers to stick with older, "safe" algorithms rather than pushing the envelope with more responsive, advanced code.
I recently consulted with Lowell Schiller, a former head of policy at the FDA, regarding potential pathways for reform. Schiller noted that the agency has not been idle; it has made significant strides to modernize its frameworks within the limits of its existing power. For instance, the FDA has issued guidance to exempt certain lower-risk applications—such as general wellness apps or simple data-logging tools—from intensive review. They have also pioneered "Predetermined Change Control Plans," which allow developers to outline future software updates in advance. If the updates stay within these pre-approved parameters, the company can deploy them without seeking a new round of FDA clearance.
Yet, these administrative tweaks can only go so far. The agency is hitting a "statutory ceiling." To truly bridge the gap between the speed of code and the speed of regulation, the FDA needs a new mandate from Congress. One promising solution involves a concept piloted during the first Trump administration: the Software Pre-certification (Pre-Cert) Pilot Program. The logic of Pre-Cert is a paradigm shift. Instead of focusing solely on the individual product, the FDA would "pre-certify" the company itself. This would involve a rigorous assessment of the developer’s internal processes: Do they have robust quality controls? Do they follow best practices for coding and cybersecurity? Do they have a reliable system for monitoring how the software performs in the real world?
If a company is pre-certified, it would be granted the latitude to iterate on its software more freely, with the FDA moving from a "gatekeeper" role to an "oversight" role. This would prioritize safety while allowing life-saving innovations to reach patients at the speed of the digital age. Unfortunately, the Pre-Cert pilot hit a legal wall. The FDA concluded that it did not have the statutory authority to fully implement such a system without a change in the law.
The opportunity for this change is fast approaching. Every five years, Congress must reauthorize the FDA’s user fee programs, which are the agreements where industry players pay fees to the agency to fund the review process. These fees currently account for approximately half of the FDA’s budget for human medical products. The next reauthorization cycle is looming, with negotiations currently underway to set performance goals and fee structures for the period beginning in 2027. This legislative window is the perfect moment for Congress to modernize the medical device framework specifically for software and the burgeoning field of generative AI.
The urgency of this reform cannot be overstated. If the regulatory system remains stagnant, we will continue to see a "bifurcated" environment in healthcare. On one side, we have the regulated market—safe, but lagging behind the technological frontier. On the other side, we have the "homegrown" or open-source market—innovative and fast, but operating in a legal and safety vacuum. This is fundamentally unfair to patients who lack the technical expertise to navigate open-source solutions. It is also unfair to medical device manufacturers, who are hamstrung by timelines that prevent them from competing with the "unregulated" innovation happening on the internet.
Furthermore, we are entering the era of machine learning and generative AI in medicine. We are looking at a future where software doesn’t just follow a static set of rules but learns and evolves based on the data it encounters. The FDA’s traditional "once-and-done" review model is completely incompatible with a machine-learning algorithm that changes its behavior as it processes more patient data. The agency needs the tools to perform dynamic, post-market oversight—essentially watching the software as it works in the real world—rather than trying to predict every possible outcome during a pre-market review.
The risks of inaction are tangible. When patients like me turn to open-source code, we are assuming "unknown risks." While the community is diligent and the software is often superior, there is no formal mechanism for reporting adverse events, no mandatory recall system for bugs, and no standardized validation of the code’s safety across different populations. Our regulatory system should not be pushing patients into these corners of the internet to find the best care.
The goal of health policy should be to ensure that the "best" solution is also the "regulated" solution. To get there, we must stop asking the FDA to simply "work faster" with the same outdated tools. We need a regulatory architecture that reflects the reality of 21st-century technology. By empowering the FDA to certify processes rather than just products, and by giving the agency the statutory authority to oversee the lifecycle of software in real-time, Congress can ensure that the next generation of medical breakthroughs is both rapid and reliable. For the millions of Americans living with chronic conditions like diabetes, these are not just abstract policy debates—they are matters of life, death, and the quality of every day in between.
