The distinction between medical devices and mobile applications is becoming increasingly hazy as technology develops, posing previously unheard-of difficulties for software developers, regulators, and healthcare executives.
The FDA started regulating software and applications for mobile devices just over a decade ago, using the same legal frameworks that govern medical equipment. Widely cited studies now demonstrate that current trends in mobile technologies stand to transform healthcare delivery, cost, and patient experiences in the future, as mobile devices have transformed how people access information and conduct transactions over the past ten years.
On the “AI in Business” episode, Urvashi Tyagi, advisor and former chief technology officer at ResMed, talks about how to make money off of digital solutions, work proactively with regulators, and streamline software design to spur innovation and expansion in the healthcare industry. Following the podcast’s taping, Tsavo Knott, co-founder and CEO of Pieces Technical, joined the two to start a more comprehensive discussion about these difficulties from the standpoint of software development.
An AI-powered software startup called Pieces creates a platform to help programmers work more productively. ResMed is a provider of medical equipment with a focus on cloud-based tools for treating chronic obstructive pulmonary disease (COPD) and sleep apnea. The company creates products like ventilators and CPAP machines, which it says improve the quality of life for those with respiratory disorders.
Together, their discussion provides useful information for healthcare executives in two crucial areas:
Decoupling codebases, enabling agility by making development jobs interchangeable, and reducing context switching are some ways to streamline development for highly regulated software products and assist developers in adapting to changing roles in regulated sectors and working environments.
Adopting the “80/20” approach for modularizing code to allow for quick modifications while preserving smaller regulated sections will help Med- and HealthTech embrace modernization and give larger legacy companies the agility of startups.
Simplifying The Process Of Developing Highly Regulated Software Products
Tsavo Knott inquires about the experience of front-line developers, specifically with regard to product development and the use of reusable modules, during their introductory talk on reducing software rework for medical software. He asks them about their annoyances and areas for improvement, bringing up the difficulties of lengthy and postponed timetables for implementing improvements.
In response, Urvashi points out that developers encounter comparable problems in both regulated and unregulated sectors, particularly in legacy settings. Numerous Fortune 500 businesses are shifting from non-technological industries to tech-driven ones, frequently working with monolithic systems. According to her, these patterns are especially noticeable in the Med- and HealthTech industries, and they reflect a well-known dynamic that corporate executives have observed in the financial services industry:
Many of the large healthcare organizations have already begun this procedure, and the majority will have to go through it. They should give this top priority soon because really creative and nimble companies will pose serious risks to the ecosystem and will actually put pressure on the rest of the sector. Similar to how the FinTech industry put a lot of pressure on the major financial banks over the last ten years, they increased their investments in the rate of financial sector innovation.
– Advisor and former ResMed Chief Technology Officer Urvashi Tyagi
Limited visibility in the deployment process and the necessity of resolving issues after delegating work to other developers are common sources of irritation for developers. To overcome these obstacles, both speakers concur that promoting flexibility and efficiency through interchangeable roles is essential.
Tsavo highlights the value of technologies that let creators continue where others left off. By increasing velocity and decreasing dependency on individual developers, these solutions enable teams to either minimize the number of developers required for a project or ship more features with the same team. The difficulties of lengthy production schedules are lessened by effective development techniques, even when regulated code acts as a bottleneck.
Building on Tsavo’s ideas, Urvashi emphasizes the necessity of avoiding reliance on individual developers in order to reduce risks and guarantee continuity in the event that someone departs the company or takes on a different project. She also recommends decoupling medical and non-medical codebases and stresses the need of making the simplest adjustments to minimize hazards. Decoupling allows for more efficient development by allowing about 80% of the code to be unregulated. She adds that change advisory boards, or CABs, are frequently set up to control production risks and boost productivity.
Urvashi lists the following benefits of a decoupling strategy:
Makes the regulatory process more effective by enabling internal regulators to concentrate on important patient safety issues rather than being overburdened by the full software stack.
Because 80% of the software is no longer subject to stringent regulatory standards, fewer problems and bugs need to be reported to outside regulatory agencies.
Urvashi then talks about how developers may concentrate on creating features and putting code into production by using incremental modernization, even though it can be inefficient at times. Continuous delivery pipelines enable for faster deployment and greater developer participation by ensuring quality while gradually changing the system architecture.
Context switching is discussed by both presenters as a significant obstacle for programmers creating medical apps. According to Tsavo, developers who switch between projects may experience a bottleneck in productivity because it feels like they are re-onboarding every time. Urvashi concurs, emphasizing that context switching has an impact on all industries, not only those under regulation:
The actual issue is, which is what we wish to prevent. Additionally, there are rather good incentives to ensure that you adopt DevOps and development TechOps methods to minimize technological debt and have a developer that is in charge of everything from start to finish. In this instance, you don’t need a manual scheme—doing QA testing from a regulatory aspect and documenting it for this 80% of the code base—because they built the code, the unit test, and the integration test. Now that the code is in production, you can proceed to your other responsibilities and enjoy a significant incentive from both a commercial and development perspective.
– Advisor and former ResMed Chief Technology Officer Urvashi Tyagi
Accepting Modernization In Health And Medical Technology
Tsavo and Urvashi then discuss the advantages of modularizing code into regulated and non-regulated pieces in order to implement the “80/20” rule. About 80% of the software used in medical devices is non-medical, according to Urvashi, and as a result, it is exempt from the same amount of regulatory scrutiny.
According to Urvashi, the method lowers development costs and improves scalability, enabling developers to offer new features, iterate more rapidly, and resolve problems without needless delays. Teams can become more agile by implementing the 80/20 model, which will help businesses stay up with the quick technology changes observed in other industries.
Urvashi highlights that huge organizations must change their architecture and culture in order for legacy businesses to become as agile as startups. Legacy healthcare organizations need to move away from local and company-specific goods and toward creating global platforms that can be implemented in various regions. In order to accomplish this change, silos must be dismantled, a collaborative culture must be promoted, and smooth processes must be encouraged.
Decoupling medical and non-medical software is also crucial from an architectural standpoint, she says, in order to:
Construct scalable and modular systems that streamline digital and device architecture.
Reduce time-to-market and regulatory complexity so developers may concentrate on value addition.
Urvashi clarifies that a company’s commitment and urgency determine the timescale for attaining such agility. According to Urvashi, businesses undergoing a transformation process typically fall into one of two categories:
Businesses that proactively launch incremental modernization initiatives and acknowledge the vital requirement for agility
Others only start these changes when their company is under danger from competition and market forces.
However, because businesses must constantly innovate and adapt, modernization is an ongoing process with no end goal. Urvashi contends that companies can enhance their skills and successfully meet needs by adopting an incremental modernization strategy, which eliminates the disadvantages of lengthy, extensive initiatives. In order to stay competitive and efficient, businesses can gradually change their architecture by implementing modernization patterns like the triangle pattern.
Tsavo goes on to say that businesses aiming for complete agility face a special difficulty as the speed of innovation is surpassing the capacity of regulatory agencies to adjust. An imbalance between innovation and regulation may result from the lag in regulatory compliance requirements, even when continuous modernization initiatives are assisting in reducing development friction.
Tsavo highlights that for businesses hoping to attain true agility in the future, it will be essential to beforehand match software innovations with regulatory frameworks.