Why we should build improvement-native medical technologies
My car gets better and safer over time - we should expect the same for medical technologies
A few months ago, my wife was driving my girls to piano lessons when another driver ran a stop sign and crashed into her driver’s side door. Fortunately, no one was hurt, but I felt more anger than I’ve felt in a long time. My girls didn’t want to take that route to piano anymore, and we needed a new family car.
As I started shopping for a new car, I was surprised by how different my car-buying experience was compared to when we had bought our last car 10 years ago. Instead of looking just at performance and safety ratings, I was looking at how much better the car might become in the future. What kinds of updates in the years after my purchase would make this car safer and more fun to drive?
I spent probably too much time reading Reddit forums about how often car companies shipped firmware updates and what these updates were like. What kind of fun holiday modes might I expect? Which drivers were happiest about how software updates improved their driving experience and the safety of their cars? Which companies had the most advanced features at rollout?
What was weird was that without really realizing it, my expectations had shifted over the last 10 years. I wasn’t evaluating a car as a finished product. I was evaluating how well it was designed to improve. Even more dramatically, I now expected my car to get better over time. I didn’t want to buy a static list of features on a window sticker; I wanted to buy something that was intentionally built to become safer, more capable, and more enjoyable after purchase.
Some folks call these types of cars “software-defined vehicles,” but the concept is broader. We’ve also come to expect this kind of experience in software and consumer electronics. Together, we might call these improvement-native products: products designed from the outset to improve after deployment through planned, validated updates. Updates to these products aren’t just to correct what might be broken; they are an intentional part of the product’s architecture and lifecycle. I now expect to have a long-term relationship with the manufacturer where they listen to my feedback and the feedback of all the customers, and make our experience better. With that in mind, I couldn’t go back to a lame car that was delivered as-is. I wanted one of these new smart cars that were designed to evolve.
If we can make cars better over time, shouldn’t we do the same for medical technologies? I think so. We should make medical technologies that do more than deliver a static set of specifications. We should build improvement-native medical systems: long-term solutions to medical problems that are adaptive, personalized, and perform better over time, not worse.
The automotive, software, and electronics industries give us a playbook for how to build improvement-native products in other regulated domains. We now also have the technical and scientific know-how to make medical technologies that can learn from data. Most importantly, building medical technologies that adapt and improve over time will deliver better outcomes for people in need - they will save lives. It’s not just that we can do it, we must do it.
Here are some thoughts about what improvement-native medical technologies would look like and how we can bring them to market.
Improvement-native vs Updatable devices
Ok, so you might be thinking (that we’ve been able to update medical devices for years, isn’t that “improvement-native”? Not really, at least not to the level of smartphones and computers. The difference is in the mindset during development, and it affects the design and operation of these technologies:
Updateable medical devices today are built to allow change.
Improvement-native devices will be built with the intention to change.
For example, most medical devices today are updated as a reaction to something that is broken: security patches and bug fixes. The main purpose of an update is to make sure the device continues to function as it was intended. Because these updates aren’t planned, they tend to be rare and disruptive.
In contrast, an improvement-native device would release updates as proactive device improvement. These devices would be designed with the explicit expectation that meaningful improvements in safety, performance, or personalization will occur after deployment. These updates wouldn’t be disruptive because, as a patient or as a doctor, I would expect these changes. I would be confident that the updates are made responsibly because the system was built with these updates in mind.
Just like an upgrade to the new OS on my phone, these updates should be no big deal. I should expect them to happen every few months, and that my experience as a user will improve. At the very least, I should be confident that it won’t affect the basic functionality or safety of my device, and I could opt out of an update if I prefer.
These proactive updates fall into three main categories:
Features that could exist, but don’t yet, like when you get a new way to track your health after an iOS update.
Features that exist, but don’t yet have enough clinical evidence for FDA approval. Medtronic shipped its recent DBS system with the ability to perform closed-loop neuromodulation, but only enabled that feature after obtaining FDA approval.
Features that can’t exist yet because we don’t have the data or know-how to build them. This is like self-driving cars. The product needs to be equipped with instruments to capture data as users experience a variety of scenarios so that there is enough data to develop, validate, and safely release a new feature.
This difference in design intent means that improvement-native devices should be built differently from traditional upgradeable medical devices. Lessons from other industries and FDA guidance suggest three key features will differentiate improvement-native medical devices from traditional updateable medical devices:
Separate safety and improvement layers: The system architecture should have a locked safety core that separates the safety-critical functions like therapy delivery and fault detection from the evolvable improvement layer that includes the event detection algorithms, personalization logic, decision support, and user experience. This mixed-criticality architecture allows improvements to be released frequently and safely because they will only affect the evolvable features and ensure the safety-critical functions remain stable. This approach is used in the automotive and aviation industries to provide safe system updates.
Instrumented to learn: Improvement-native devices should be instrumented to record data related to intended use, safety, therapy effectiveness, variability across users, and drift over time. By capturing this data, developers can create new features informed by user data and evaluate their performance based on real-world use. This feedback cycle allows the kind of rapid improvements we’ve seen in the software industry.
Planned and governed updates: Updates should be released regularly, with a predetermined change plan that is approved by the FDA and communicated clearly to users. This is already supported within the FDA’s Predetermined Change Control Plan (PCCP), which provides a mechanism for regulators and manufacturers to agree in advance on what types of changes may occur and how those changes will be evaluated.
Keys to Success
Cars, aviation, and smartphones have taught us what it takes to make a successful transition to improvement-native devices:
Improve often, but in small, understandable steps
Modern cars get regular updates that improve safety systems, driving assistance, or reliability. Smartphones follow the same pattern: users don’t wait years for a new phone to get better performance or security—they expect gradual improvement as part of ownership.
These updates are also “quiet”. When your phone battery lasts longer or your car brakes more smoothly, you don’t feel like you’re testing a prototype—you just feel like the product works better.
Medical technologies should follow this same rhythm. Smaller, well-validated updates. Patients should never feel like they are part of an experiment. Improvement should feel like maturity, not trial and error. With each update, they should receive clear communication about what is changing and why. They should never feel like this is something happening to them without explanation, and they should be able to opt out if they prefer.
People have come to desire regular updates to their cars or phones because their experience has taught them that updates are predictable, governed, and usually beneficial. Medical technologies must earn that same trust. We should clearly communicate the rules guiding our updates and adhere to these rules when we deliver regular and safe improvements. These improvements should simply be what people expect as part of the ongoing care they receive from their medical technologies.
Learn with everyone, not just with clinical trials
In aviation, safety improvements come from aggregating data across thousands of flights, not isolated incidents. For “software defined vehicles” today, improvements are based on driving data collected daily from thousands of drivers, not just from professional drivers on factory test tracks.
Improvement-native medical technologies should do the same, responsibly. Improvements should be based on learning from diverse patients and care settings. The variety of data no single clinic or clinical trial could collect alone. Obviously, this is sensitive data so it should be collected with consent and be protected and anonymized, but importantly it should benefit the people who are sharing the data. The products should get better for them and everyone else who suffers from their condition because they share the data from their user experience. The system shouldn’t be learning about the users so much as it should be learning with the users, helping them to improve their own care and the care of everyone in their patient community.
Roadblocks and opportunities
Ok, so if this would be so great, why aren’t medical devices already improvement-native?
Legacy architectures weren’t built to change. Opportunity for new startups.
Incumbent medical device companies have decades-old hardware and software infrastructure that makes it difficult or impossible to implement improvement-native behavior. This is because the average development cycle for a new active implantable medical device is approximately 5-8 years1, so most of what we see on the market today was designed in an era where post-market change was rare, and consumers had yet to expect ever-improving products. These legacy architectures typically have tight coupling between safety-critical functions and non-critical features that would benefit from improvement. To make these systems improvement-native would require a dramatic redesign or retrofitting of the underlying hardware and software architecture. As I discuss in the next section, it may also be true that the economic incentives may not yet exist to justify the expense of developing new types of architectures within traditional medtech environments.
This roadblock for incumbent medical device companies is an opportunity for startups. By building our architectures now, from the ground up, we have the freedom (and I’d argue the moral imperative) to build improvement-native architectures. Architectures that incumbents cannot build due to the legacy hardware and software infrastructure that supports their existing product lines.
Insurance typically pays for medical devices up front. Opportunity for payment-over-time to align economic incentives with patient outcomes.
Insurance companies traditionally pay upfront for medical devices, but improvement-native systems require ongoing work: monitoring real-world performance, developing and validating refinements, and deploying updates. The growing shift to value-based or outcome-based payment may change the incentives to better support improvement-native design.
Upfront payment makes sense when the value of a device is fixed from day one, but it doesn’t make sense for improvement-native devices that create more value over time. More importantly, it fails to incentivize continued improvement, which may be one reason why we don’t see more improvement-native medical devices today.
Payment over time better reflects how value accrues in these technologies and aligns incentives around outcomes rather than delivery. This is particularly relevant for chronic conditions such as mental health disorders, where costs are driven less by the initial intervention and more by relapse, hospitalization, and emergency care. For example, annual per-patient costs for severe depression can easily exceed $20,000–$30,000, with hospitalizations alone costing $10,000–$15,000 per admission. Even modest reductions in hospitalizations and emergency care can translate into thousands of dollars in annual savings per patient.
There are many ways to revise payment to better align with payment for outcomes or value rather than paying for services. Examples like value-based contracts, prescriptions, or hybrid models—better align economic incentives with patient outcomes.
In such a revised payment model, insurance providers can lower the total cost of care by paying for better healthcare outcomes that reduce healthcare utilization. They also do not bear the costs of care if the patient switches insurance providers, which happens on average every three years.
Companies are incentivized to develop and release improvements that improve healthcare outcomes through greater therapeutic efficacy, patient adherence, biomarkers, and event detection.
Patients get the better care they deserve through continuous improvements that actually improve their healthcare outcomes.
The idea of prescription or payment-over-time models can seem scary, particularly for something as important as chronic mental health conditions. Yes, I’ve seen that black mirror episode, and it’s frightening. But we’ve already found ways to manage this risk in the case of life-saving prescription medications. We should apply the same medical technologies continuity-of-care requirements to medical technologies. Things like refill grace periods, prior-authorization continuity, appeals processes, and patient assistance programs. It should be possible to pay for improved performance, but never remove the key life-sustaining support that medical technologies provide.
Paying once for a device assumes its value is fixed; paying over time for performance updates that improve outcomes helps to ensure that care improves over time.
Improvement-native tech for mental health is just as important as driver safety
Building improvement-native cars is a moral imperative. Traffic accidents are a leading cause of death, claiming 40,000 to 45,000 lives in the US each year2. We owe it to drivers to build improvement-native cars because that is the best and fastest way to make cars safer.
Suicide claims more lives than auto accidents in the US, roughly 49,000 a year, according to the CDC. Unlike motor vehicle fatalities, that number is climbing. If we include deaths of despair that result from mental health disorders like depression and substance use disorder, that number is even larger.
When we build medical technologies for mental health, like we are doing at Motif Neurotech, we owe it to people that we build improvement-native technologies. Just like in the automotive industry, this will be the best and fastest way to deliver safer and more therapies to the people in need.
If we accept that cars should get better over time to save lives on the road, we must also demand that health technologies get better over time to save lives in the clinic and at home. We have the technology. We have the know-how. It’s up to all of us to build improvement-native medical technologies. It’s a moral imperative.
Jacob Robinson is co-founder and CEO of Motif Neurotech and a Professor on leave from Rice University in Houston, TX.
Acknowledgments: Thanks to Steve Goetz and Nick Halper at Motif, who helped review this article.
Use of AI: I used ChatGPT to research and source references for this article, but I wrote the text with good old-fashioned natural intelligence. Typos and all…
https://nextern.com/2023/05/17/how-long-does-it-take-for-a-medical-device-to-make-it-to-market/
https://www.iihs.org/research-areas/fatality-statistics/detail/yearly-snapshot?utm_source=chatgpt.com