HOW TO SPEED INNOVATION WHILE REDUCING RISK
– Four strategies to succeed
Most companies are already on their journey to digitizing products. This is too often done on a product-by-product basis, either designing each product and its software from scratch, or buying in software solutions and bolting them on to products.
For software-enabled products, a whole-portfolio approach is far more sensible than product-by-product. Companies innovate far faster when they have the software fundamentals in place to support their entire portfolio. This broadly falls into two categories: the tech stack and software frameworks.
A robust tech stackThe tech stack comprises the underlying interconnected technologies upon which your entire portfolio of devices will operate – consisting of a cloud-based platform and a related software development environment. The cloud-based platform is the infrastructure on which applications are built and hosted, and the central point for managing accounts and devices, sharing data, and integrating the whole product ecosystem in a single place. The software development environment includes the processes and tools to develop and manage the software product, including development, integration, test, pre-production, and production. It ensures speed and consistency across products.
Software frameworks
Building software-based products efficiently and at scale requires our second fundamental of rapid software innovation: frameworks. Frameworks are tried-and-tested approaches for building certain types of products that reduce a great deal of the work. They can include approaches to iterative product development, the core building blocks of the products, and blueprints that tie the pieces together. Frameworks provide consistent ways of working to innovate rapidly, while making it easy for teams to collaborate and pick up each other’s work.A good framework will include a library of pre-built, pre-tested software modules. These are pieces of code, built on a common software foundation, that make up common elements of a medical product that can be deployed into a wide range of applications across your portfolio. Modules cover services, such as accounts and access management, consent, prescription management, appointment booking, device connectivity, therapy management, and EMR/EHR integration.
A framework also includes blueprints that provide sub-sets of functions to fulfill specific use cases, such as treatment adherence, remote monitoring, disease management, or decentralized clinical trials. A good framework allows modules to be flexibly combined and should also be flexible enough to integrate custom or third-party components.A library of modules for IMPS should only use modules that are compliance ready. Modules are compliance ready if they are built in a medical grade, design-controlled environment using ISO 62304 processes with qualified tools, all necessary documentation, traceability, and automated test cases. The framework should be compatible with GxP non-device medical data systems all the way up to FDA/EU MDR device Class III/IEC 62304 Safety Class C.You may design an innovative diagnostics AI from scratch, but you can also use frameworks to streamline the approach and quickly develop the bulk of standard elements that make up the rest of the product and production. It ensures speed and consistency across products.
The benefits of a modular approachUsing such modules makes everything more agile and can reduce new device development effort by 50% or more. Modularization and automation of as much as possible – especially in software verification – are fundamental to speeding development, increasing product quality, and reducing post-launch maintenance and compliance efforts.A modular approach represents a sensible balance between designing from scratch and buying off-the-shelf software solutions for your medical product. The former puts you in complete control, but is slow and costly, and introduces lots of potential points of failure. The latter may be faster and cheaper, but makes it difficult to adapt and improve products post-launch. A modular approach using frameworks removes a lot of the hard development and testing work, while enabling ongoing customization of individual building blocks without having to redesign the whole product whenever user or regulatory requirements change.
Designing and building state-of-the-art medical devices and platforms requires deep expertise in the product, the data, and the software environments.Software must be written to work for the product, and the context in which it will be used. This includes an understanding of the sensors and inputs, and the connectivity used to interact with all other software involved. The importance of communication within the system makes deep consideration of cybersecurity and privacy essential. That is simpler if you own and control the device, but much medical software is designed to run on a phone, laptop, or third-party medical device, and so a clear cyber strategy is essential.
Additional thought needs to be given to how third-party systems outside your control may change over time (Apple releases a new major version of its operating system every year, for example, but also released 17 interim security updates in the past year). Maintenance costs can account for over 75% of total lifecycle costs. Wrong decisions in software design that don’t build in sufficient flexibility can cause maintenance costs to explode and destroy the business case.AI is the jewel in the crown of medical-device innovation, offering the potential to personalize advice and predict health outcomes. But AI can also be opaque.
High accuracy is not enough – we must be able to understand the reasoning. That means not only that the approaches to data collection are rigorous, but the whole AI design must be ethical – and include considerations such as clearly defining the benefit, transparency, explainability, privacy, safety, and development by diverse teams to minimize risk of bias – so both patients and doctors can understand and trust the recommendation.
Attention must also be paid to designing the user interface so that users want to use it. This means making human factors central to design for simplicity of use and visualization of data, but also to provide behavioral nudges through gamification and personalization to incentivize desirable behaviors (such as drug adherence or making the device part of a routine).All this needs to be supported by robust and efficient processes to ensure products progress quickly, from feasibility studies, model-based systems engineering, design, and development, with checks throughout to solve problems before they become ingrained.
When developing medical-grade software products, we must give due consideration to regulatory compliance. A small error can mean failing regulatory approval, setting projects back months, undermining market confidence, and potentially losing out to competitors. Remediation efforts, especially in response to an FDA warning letter, are usually extremely expensive.
The FDA list of software-related recalls makes for sobering reading: “software defect,” “false upstream alarms,” “firmware error,” “login error,” “software bug,” “sensor failure,” “cybersecurity vulnerability.”
But compliance is also time consuming and can account for up to 30% of total product development costs. Complexity is amplified as compliance expands into unfamiliar areas such as analytics, real-world data, AI diagnostic recommendations, remote patient monitoring, and sensor data interpretation – all of which are subject to still-evolving regulations, which may be new to life sciences and medtech.
The most efficient route to launching compliant products is to build compliance into the device lifecycle from the onset. Ensure your software development frameworks are aligned with regulations, with relevant checks and testing as you go. This can be accelerated by using pre-built compliance-ready modules for non-bespoke elements, as discussed above.
Speed overall compliance with different processes for different risk levels
It is also expedient to divide the product into modules for compliance purposes. That way, lower risk and non-medical components can be developed with less effort, reducing the overall burden.We can think of a core of SAMD-components performing the heavy lifting – analyzing and processing medical data and generating insights and recommendations – and these usually need to meet pre-and post-market regulation. Other routinely used components, providing support functions such as communication, user guidance, and routine task administration, often do not need to meet the same standards. Both FDA and EU regulators recognize that medical devices can have both medical and non-medical functions. Regulatory alignment will be quicker if we define the boundaries of the medical and non-medical modules and assign risk categories (high, medium, and low). Then, we can apply appropriate standards and testing to each, as well as check that the non-medical parts will not compromise the system as a whole. But there is no need to test everything according to the standards appropriate to the riskiest component.
A risk management exercise
Meeting regulation is one of the most time-consuming and risky parts of product development, with many potential points of failure. Using compliance ready modules from risk-based IMPS frameworks helps reduce complexity, allowing risk management to the focus on new innovative elements rather than the whole product, reducing the total effort. This also decreases time to market. Developing software for medical devices that is compliant with software and data regulations can be daunting, especially for those who do not yet feel mature in the world of compliant software for medical devices. Those who do not yet have the full suite of in-house software and regulatory compliance skills may consider working with a partner that can also act as a certified legal manufacturer. Such an organization can take on the risk and complexity of compliance and related activities, such as post-market surveillance. Such a partner will not only have full engineering development capacity and a workforce experienced in using frameworks, processes, and modules, but also the extra elements needed to develop software for medical devices that meet regulatory standards, submit regulatory documentation, and manage compliance post launch.
Organizations that are legal manufacturers work closely with you to define needs and goals but use their own approaches to software development and, ultimately, take full legal and financial responsibility for pre- and post-market regulatory compliance of any SaMD product.
Many life sciences and medtech companies lack the core software skills and culture, more typically found in tech companies, to routinely build, launch, and manage intelligent digital products and to ensure that software aspects align with regulation.To ensure they innovate at their full potential, these companies will need to bring in more software expertise. This must include expertise in designing software in regulated industries, across traditional domain boundaries of standalone medical devices or clinical systems, and into the real world. This will need to be done through a mix of recruitment, retraining, and outsourcing. Not everything can be done in house, nor should it be (anyway, there simply are not enough software engineers for every digitalizing company to meet all their needs in house). Most successful digital transformers focus on developing their core digital IP in house and outsourcing everything else.These companies will also need to build an ecosystem of partners to provide the parts they do not have themselves, from cloud providers such as Amazon, Microsoft, or Google, to companies providing advanced technologies and services for device connectivity, to software development and testing consultants. This large ecosystem may be managed through the supply chain function, or via a single systems integrator.They will also need to create a culture that joins traditional medical product developers with digital teams. Device engineers will need to understand the needs of the software teams and work closely with them. Some software engineers – especially those recruited from tech – may find the approach of launching beta products and improving quality through testing and feedback needs to be retrained to be better tuned to the rigor of the medical industry. The medical industry can and should profit from agile and continuous integration/continuous delivery principles that apply small, incremental, or frequent updates to improve quality at speed, rather than large irregular upgrades. However, this needs sophisticated engineering practices and management, along with careful cross-training and teambuilding between teams from very different backgrounds.
