Contrary to most reports, prices for medical devices have actually been growing far more slowly than the Medical Consumer Price Index or even the overall Consumer Price Index. Over the period from 2009 to 2019, medical device prices have increased at an average annual rate of only 0.4 percent, compared to 2.9 percent for the MC-CPI and 1.8 percent for the US CPI[1]. This relatively slow rate of price increase suggests the industry has been highly constrained in capital expenditures.
Value creation in the medical device industry is inexorably shifting from ever-more sophisticated electro-mechanical devices towards software – both complex, embedded controls and, increasingly diverse software-as-a-service (SAAS) based AI powered software analytics and workflows. Over the past ten years, this sector of the healthcare industry has been growing rapidly, doubling between 2016 and 2021, to $6.1 billion in the US, with an expected tripling to $19.7 billion by 2028[2], with the global market expect to grow to nearly $50 billion by that time[3].
Increased functionality within software has come with increased FDA scrutiny of these new software capabilities and systems. Over the past few years, the FDA has been exceptionally aggressive in rolling out new regulations on software within the medical domain. New liabilities associated with software cyber security, new rules on the development, testing and field monitoring of AI-based systems, new guidance on Software as a Medical Device (SaMD). This, in turn, has had a knock-on effect on the companies and organizations that are responsible for the development of these new products.
The regulations and guidelines are designed to increase focus on software development and test processes. Emergent catch phrases such as ‘Security by Design’, ‘Quality by Design’ and “AI by Design” emphasize that the goal is to shift the industry away from a legacy of too many shortcuts in the software development process.
Medical device OEMs, large and small alike, consistently have made development mistakes that have often resulted in delayed programs, elongated approval cycles with the FDA or opening of financial liability under the new regulations. As proof of the seriousness of the challenge, software issues have consistently been the leading non-manufacturing cause of device recalls for the past decade[4].
To make things worse, FDA statistics show that 90 percent of all software related product recalls are related to design flaws. (The remaining 10 percent had to do with managing the configuration such as shipping the incorrect version.) While electronics can fail due to the reliability, stress, and wear of individual components, field failures today are more often caused by faulty design and development. That’s why regulators are increasingly focused on the design and product-validation processes.
Oftentimes, OEM developers try to “save time” minimizing the perceived “overhead” of these formalisms of system and software testing early in the development lifecycle. But this approach incurs the risks of potential product failures that can harm patients and others, product recalls that can damage the credibility of a company, cost millions, and bring about painful actions from regulators.
Risk analysis and risk management activities are crucial to the design of safe devices, as detailed in industry standards such as ISO 14971. They involve identifying and reducing risk by limiting the potential severity or probability of an operational failure by including risk control measures in the product design process itself. This process iterates until the residual risks are reduced to acceptably manageable levels.
Another common and painful mistake OEM device designers make relates to engineering design and regulatory required controls of the design and development process. Many medical device OEMS are staffed with engineers from non-medical device industries who may not be convinced that engineering processes are an enabler to product development success – irrespective of the mounting evidence of the negative impacts of poorly followed engineering processes.
Design engineers sometimes resist a well-defined development lifecycle with formal reviews. This often manifests itself as not using ‘Design Driven’ engineering practices which strictly design products through documented requirements and specifications. This lack of process will not only destine development programs to many testing iterations as the design asymptotically narrows in on the final solution and but also makes thorough verification by independent testers nearly impossible. This approach is exacerbated by the need to demonstrate process control throughout the development effort. Too often, near the end of the project, quality and regulatory engineers descend to prepare documentation for submitting the device to the FDA. If a process was not predefined or was not followed, they “retro-document” the project to make it look like it was managed under well-defined design controls. Engineering teams justifiably resent this process, considering the documentation a waste of time. Unfortunately, they’re right! If designs are not driven from documented requirements, or if software and circuits aren’t implemented from documented designs, the value of having those documents (for other than regulatory purposes) is significantly limited.
Too often, the one and only design review is hastily organized and occurs at the end of the development project. Often coupled with an afternoon-long Failure Modes and Effects Analysis (FMEA) meeting held almost solely to satisfy risk management requirements. The “final release” is handed off for some quick testing so the product can get to market- usually, because it is later than scheduled. Rather than performing all these activities integrally with the development effort where they add real value in terms of quality and efficiency, packing them in at the end of the project to satisfy the regulations simply ignores the intent of the regulation.
Engineering quality is seldom more critical than in medical devices. The medical device industry is a serious business, and the FDA won’t tolerate violations. Implementing a solid development process will not only improve quality and save time – it improves profitability and saves lives.
[1] From “Estimates of Medical Device Spending in the United States” by Gerald F Donahoe, June 2021
[2] From The United States Healthcare Software As A Service Market Size & Outlook, Grand View Research, 2021
[3] From “Healthcare Software As A Service Global Market Report 2024”, Research and Markets, 2024
[4] From “Identifying Root Causes: Challenges and Trends in Medical Device Recalls”, by Ranj Zuhdi 2024