Back in 2011, Marc Andreessen stated that software is eating the world. Over the last 15 years, more and more businesses and industries have been run on software and delivered as online services – from movies to agriculture to national defense.
Medical devices increasingly rely on software. Digital health solutions are by nature composed of software. Artificial intelligence solutions are entering healthcare and these are, above all, software. Software is eating the world.
However, there is a major difference between the usual software startup mantra of “move fast and break things” and the healthcare sector. Health innovators have no room for errors and mistakes. The quality of the products is critical, software bugs are a luxury that they cannot afford, and the patient/user is at the center of all concerns.
Regulators in the US and in the EU have put strong frameworks in place to ensure that the population stays safe, and software has been under greater scrutiny in recent years, mainly in terms of risk management, AI training, software lifecycle management, cybersecurity, risk/benefit analysis, and many others.
By nature, software is complex because it is composed of many components. A bad user interface (UI) could lead to erroneous usage. A vulnerable dependency could lead to a leak of personal health information (PHI). A flawed algorithm could make a bad or biased decision. An updated web browser could suddenly make your application crash.
The software industry is accustomed to managing problems through continuous iteration. Iterating on the product allows developers to reduce the number of bugs, improve the user experience (UX), and secure the solution. But how can health innovators continue iterating while keeping pace with regulations?
As CTO in medical devices and digital health solutions, I designed with my team a framework to ensure continuous improvements while staying compliant with the latest regulations. This is how we dealt with it.
Dual-Track Development: The Secret to Seamless Compliance
At the core of our framework, we decided to maintain strong traceability across the code, requirements, risk controls, and verification tests. We relied on two software tools to accomplish this.
The first is a platform to manage tickets, the codebase, and automated build pipelines (to test, build, and ship code to production). The second is a platform to handle the different components of the V-cycle and maintain links between items (user needs, risks, risk controls, requirements, specifications, test cases, test runs, etc.).
From the early days, we decided to clearly segregate duties between regulatory compliance and software engineering. Ideally, software engineers don’t need to know all the compliance details to focus on their craft. This is the main reason we stuck to a dual flow for each ticket.
The whole process is supervised by the CCB (Change Control Board), composed of the CTO, the Product Owner, and the QARA Manager; others may join depending on the needs. The CCB meets once a week to address pending discussions and new tickets. This group is responsible for planning developments and ensuring that all regulatory aspects align with current regulations.
The process above appears linear, but everyone in software knows that this is unrealistic. Tickets move back and forth through the flows. The important thing here is that the two flows (software engineering in purple and compliance in green) evolve independently until the CCB agrees to close the ticket and make the changes available to users.
Three-Layer Defense: A Bulletproof Testing Strategy
Ensuring that end users are not affected by any defects is key for the performance and safety of software in medical devices. However, proceeding with complete verification at each release is a time-consuming task.
We improved the testing capabilities through multiple testing methods.
The first line of testing involves the software engineer. The definition of “done” implies that they have tested the feature or bug fix. While this testing is mostly manual at first, software engineers must add a unit test to the automated unit test suite.
The second line of testing is fully automated. The unit test suite is executed at each build. This is why it is easier to have the codebase, tickets, and build pipeline on the same platform.
When the new feature or fix is available in the acceptance environment, the product owner validates the feature’s alignment with medical documentation and verifies it behaves as expected. The CCB closes the ticket only if both the development and documentation are approved. The new feature then becomes part of the next release.
When a release is ready to be deployed to users, a final round of testing is performed. The verification team tests specifications that mitigate risks to ensure that the level of risk for the patient remains under control. Additionally, an automated end-to-end test suite is run on the entire application. If everything passes, the release is approved for deployment.
One-Click Compliance: Streamlining Documentation with Modern DevOps
To ensure reproducibility of builds and deployments, our process relies extensively on CI/CD pipelines (Continuous Integration & Continuous Deployment). These pipelines are configured to build and test automatically throughout the development process.
The deployment to environments is not fully automated because the CCB must approve the deployments. However, deployment is performed with one click in the software engineering platform (only when all previous steps have passed).
Building software for medical devices or digital health solutions comes with numerous reports for regulators. In our build pipelines, we include the generation of test reports, vulnerability scans, code scans, and (partially) release notes. When it relates to software, 90% of the reports are fully automated without burdening the software engineers.
This is how we successfully delivered new features to users with very few bugs.
Is this the silver bullet workflow? Probably not. Each organization has its own ways of working, and agility is not about applying Scrum (or another framework) by the book. True agility is about delivering consistent value to users efficiently.
Regulatory requirements often slow down software delivery. Automating time-consuming tasks, such as generating reports and running extensive tests, is key to restoring efficiency within software engineering teams.
By Olivier Staquet, CTO at Gabi SmartCare and Managing Partner at Techanism
