Bridging the gap between modern software development and medical device regulations
Guest blog by Erik Heuer (HeuerONE consulting)
The processes and methodologies used today to develop high quality software have evolved tremendously over the last couple decades. These improvements have led to more innovative and sophisticated medical software, but they have also far outpaced the slower evolution of regulations and standards. Finding a way to bridge this gap is crucial to success, both in terms of compliance and in terms of leveraging the latest software technologies and methodologies. Medical device companies that can bridge this gap efficiently will be able to accelerate value delivery to their customers up to the level of modern, high-performing software companies.
I began my career as a software engineer focusing on computer graphics. Over time I expanded into software architecture and delivery management before finally specializing within the medical/healthcare side of software development just over 20 years ago. Since then, I have witnessed a minefield of issues surrounding software used in medical devices. Balancing new tech with old regulations and standards, while still trying to make the entire development process work for everyone involved, was a messy and difficult endeavor. And I realized that the answer was not necessarily to balance these two seemingly disparate aspects of product development, but rather to integrate them into one streamlined system.
Broadly speaking, my solution is to separate the innovation and compliance aspects of medical software development and work on both simultaneously. Instead of documenting then developing, both are happening in sync. This means medical device companies should try to maximize the amount of electronic digital integrations and tooling within the product development life cycle so that there is no physical paper (or physical signatures) required for documentations. In other words, a 100% digital experience and integration.
The Value of Operations and Continuous Improvement
The Emergence of DevOps
Over the last decade or so, DevOps has emerged as a quintessential approach to address operational challenges of complex distributed software products. The DevOps methodology combines software’s development and operational needs into an infinite loop of creation and monitoring.
DevOps emphasizes active monitoring and operational data collection of the software running in production. Instead of waiting for feedback or failures to occur, you are proactively detecting issues informed by best practice risk management. Both developers and operations can work together to define and detect software problems and correct them early and often before it affects users. This is frighteningly easy to do today with the right tooling and infrastructure.
Observability – Listening to Your Products
Any software application that runs on our smartphones can send data back to a central location and indicate whether or not the application is functioning properly and how it is being used. This monitoring ability allows companies to significantly improve the safety and efficacy of their software as a medical device. But it’s also a lot of data. And in the case of medical device software, possibly a lot of personal and health data too, which brings up issues of privacy and security.
The interesting challenges surrounding user and performance data collection is beyond the scope of this article but worth mentioning. As the development of medical device software becomes even more complex and fast-paced, companies need to prevent health and personal information from being included with the operational monitoring and performance feedback. Everything around data privacy and security, as well as other compliance aspects, should be managed in a way that protects personal health information (PHI) from unnecessary exposure.
The Need for Documentation Automation
Automated document generation creates a seamless digital experience for everyone involved in medical device software development. This change is more than the adoption of electronic quality management systems. It’s the adoption of a new pedagogy where document generation is fully integrated into the company’s value creation process. And the goal is for the entire development team (including people who are not software engineers and who don’t understand code) to gain confidence that the software has been properly tested and works as specified.
Another aspect of automated, digital software documentation is the ability to trace a feature from its initial definition all the way through design, development, and testing. Everything is properly recorded and reviewed within the feature’s set of documentation.
20 years ago this level of detailed traceability would’ve been nice to have, but not essential. Back then, the FDA would rarely request to see the source code whereas today there are plenty of scenarios where the FDA would require it. This is where the traditional style of paper documentation in a modern company can undermine compliance over time–paper documentation simply can’t be as up-to-date and detailed as digital documentation. And the traditional process definitely can’t be as collaborative or intuitive.
We now have very visual tools for software development. As developers design a new feature, for instance, those edits and added assets are then automatically included in the new design’s documentation. Software engineers collaborate with product managers and other team members to write individual user stories for how each piece of a particular feature will be implemented. And as the stories are being written, new or additional acceptance criteria must be included which then dictate the kind of testing required. And those tests must be developed to automatically run as part of an initial verification anytime the software is updated. In other words, by using software development tools like Selenium or Cucumber, teams are writing software code in conjunction with testing acceptance criteria–i.e. test-driven development.
To me, the need for automated, digital software documentation is obvious. But the long-standing lack of integration between lean/agile software methodologies and compliance requirements makes the conceptual switch from traditional documentation difficult. And documentation remains one of the key challenges plaguing medical device companies. Making that switch to a 100% digital integration, however, is worth the short-term headaches.
A Painful Experience in Non-Compliance
The danger with sticking to a traditional paper documentation mindset is that any small discrepancy in compliance could become a major problem. Years ago when I worked for a large medical device company, the FDA conducted an audit and found that certain modifications to a medical device being manufactured had not passed design controls. This was an issue with design transfer in particular, and development in general. The company had to shut down all manufacturing while both processes and designs were updated to ensure that all the proper design controls were in place and that any modifications would be properly tested and documented.
It took a long time to achieve the required level of compliance. During this extremely painful time, some older systems the company had been manufacturing had to be terminated because they couldn’t reproduce the appropriate design documentation underlying the manufacturing. There was a significant difficulty in getting software engineers who were really good at writing code and developing software to write documentation that people from a regulatory background could readily understand. Everything that wasn’t properly documented now needed quality documentation on how the software was designed, how it needs to be tested, and how testers can verify all functionality and validate every intended use of the device.
We were fortunate–the whole stressful affair resulted in a new product line and platform launch. But think about how much more the company would have achieved if years and thousands of employee hours weren’t spent fixing compliance documentation and updating quality management systems.
Documentation Automation Today
Fast forward 20 years and a company can now relatively easily implement a fully digital quality management system with all the appropriate design controls, and fully integrate it with all the existing processes involved in designing, developing, releasing and operating medical device software. And every piece of automated documentation reflects the most up-to-date modifications and capabilities. There’s no disconnect between compliance and software development–it all flows together much more seamlessly.
The grief my former employer encountered over updating paper documentation discrepancies would not have happened if we had some form of automated document generation. Any code change (AKA defect repair, refactoring, new story, or feature) is now traceable and digitally controlled. So any code change can be traced back to what caused the change (whether a bug fix or field complaint, for example), who changed it, and how it was tested. This makes it easy to pinpoint any discrepancies or mistakes, and to eliminate human errors and the need to manually create documents.
Now, multiple fixes and modifications can act as proof of the development team’s ability and dedication to value delivery, rather than as a documentation “for credit” liability.
The Wheels of Innovative Discovery and Clinical Compliance
Because the operational aspect of modern software is as important as its development (also referred to as “you build it you run it”), teams must allocate space for both continuous innovation and operations. And crucially, these two processes (or wheels) need to operate in sync at a formal design review when a prototype is ready to be commercialized.
Below is my depiction of these two wheels–the left represents the learning, discovery and innovation environment where the team has maximum flexibility and minimal controls and the right wheel represents the clinical and operational environment where the team must adhere to rigorous design controls and documentation.
Having both process wheels allows for rapid innovation within a safe simulated environment as well as a rigorously controlled release to market (or to a phase of clinical trials) including the operational aspects around how the released software performs when used.
The first wheel is where teams build prototypes and test new technologies. Teams may receive some early feedback from clinical users, but all the traditional design controls are generally not applied. Otherwise the innovation and creativity process would slow down to a trickle. The goal is to experiment, fail fast, push the envelope, and learn how best to build your company’s particular kind of medical device software. When the product concept and software development requirements are well understood (maybe one of the prototypes is selected as a candidate for production) then product development enters the second wheel where many of the unknowns that typically slow down software projects are already known by the team.
The second wheel includes the full rigor of design controls, including verification and validation, design transfer, and release to market. The lower green half of the wheel is where you file necessary submissions to obtain regulatory clearances before releasing the product to market. 20 years ago, this is where product development would end. But now development continues even after the medical device is “finished.” This is because the actual use and operational aspects of the software are as important to get right as its initial development and testing before release.
The upper half of the second wheel represents post-market feedback and observation of the released software as it is being used (listening to your product). Fundamentally, the development team at this stage is still improving and testing the software to make sure that it remains safe and meets all of the intended field uses. After release the software is now working in its clinical habitat, not a controlled test environment, where you can learn a lot by monitoring how it is being used. The software you build could be running on a device that your company also developed, or, as is increasingly the case, on a completely separate platform. For example, companies like Amazon, Google, or Microsoft could provide the cloud environment to run your software and companies like Apple or Samsung could provide a physical device (like a tablet or smartphone) for the patient or doctor to use. So while you are only responsible for the quality and effectiveness of the medical software itself, you will need to make sure your software works with these different platforms and devices as they continuously evolve. With proper application monitoring it is possible to detect software anomalies and bugs as well as any unexpected or unintended uses that may need to be fixed. Having the ability to quickly resolve issues, improve the product, and redeploy is a critical capability to keep your medical device working as intended.
Here’s where medical device software development becomes even more complex. Even if you’ve confined your medical device application to work only with Apple iPhones, for example, your application will still need to function on multiple iOS operating systems. And how often Apple chooses to release an update, or how often iPhone users actually update their iOS is completely outside of your control. Understanding your software product’s dependencies on certain platforms, its compatibility with older OS versions, and testing for new capabilities is critical.
The current speed at which software can be developed, tested, and reworked was impossible 20 years ago. The slower, paper documentation that once fit with the software development model is now obsolete. Compliance documentation needs to keep up with modern software development processes and the continual product updates and adjustments being made.
Summary
The traditional model of medical device software companies considered development “finished” once the product was released to market and entered the maintenance phase of the product life cycle. Updates to the product (whether as a bug fix, additional feature, or a better user interface) were few and far between. Traditional paper documentation, although laborious, could still keep pace with code changes.
Today’s medical device software companies, however, know that the operational aspect of software is as important to get right as the development itself, and will continually update and improve their software after its launch. It’s easier and faster than ever to collect data from different software platforms and devices on how the application is operating and being used. It’s easier and faster than ever to update and change the software being used. And automated document generation systems make it easier and faster to update documentation with each change for traceability and audit purposes. What once might have cost millions of dollars worth of labor to do is now almost instantaneous. Instead of developing software then documenting, both could be happening in sync.
Innovative discovery and regulatory compliance can, and should, work together. And with the proper quality system procedures, not only do both processes work together, they work well for all stakeholders.
Further Reading
About the Author
Erik Heuer has over 20 years of executive leadership experience and success in software product building for the healthcare industry. He’s passionate about improving people’s lives, health, and well-being through customer and patient-centric products that deliver high-quality care solutions.
Erik’s broad areas of expertise include software engineering, agile development, medical devices, diagnostic imaging, healthcare informatics, telehealth, cloud computing, DevOps, and AI/ML big data. His experience spans from startups such as Auxogyn, Akiri and Fruit Street Health to multi-billion-dollar corporations such as Philips, GE and Change Healthcare. See HeuerONE for more information about his consulting experience and consulting services.
Erik holds a Bachelor’s in Electrical Engineering & Computer Science from the University of Southeast Norway and an MBA from the Norwegian Business School of Management (BI).
Pingback: Newsletter V. 2021 Issue 2 - Sunstone Pilot, Inc.