HTD Health’s novel approach to building compliant medical device software
The connected device market has seen rapid growth over the past decade with over $10 Billion in funding secured for the past three years in a row. Deloitte predicts that the global Internet of Medical Things (IoMT) market—which consists of medical devices, software, technology, and services—will grow to a staggering $158 Billion by 2022. Next generation devices are demonstrating value for providers and patients alike:
The immense potential of connected devices does not come without strict guidelines and resulting development challenges. Understanding level of risk and corresponding compliance requirements is key to designing and building software that acts as a medical device or supports device hardware.
Regulatory authorities, especially the US Food and Drug Administration (FDA), have long overseen the development of medical devices. In past decades, these organizations focused primarily on software embedded in or accompanying hardware medical devices. However, the rise of Software as Medical Devices (SaMD)—software that acts as a device without accompanying hardware—has led to questions about how existing regulations apply to emerging, increasingly software-driven technologies. The International Medical Device Regulators Forum (IMDRF) has developed guidelines for defining and understanding compliance requirements within the connected device ecosystem.
Whether a connected hardware device or SaMD, the FDA recommends software design and development documentation according to the Level of Concern (or risk) posed by the medical device software. The specific requirements vary, but documentation generally includes:
Due to the structured nature of FDA documentation, hardware device development traditionally followed the waterfall model—a stepwise process in which requirements are dictated at the start of a project and design, implementation, and verification follow accordingly. In the world of software, however, this stepwise approach is far too simplistic and rigid. Outlining requirements up front means that system updates or changes may not be realized until development is complete, which may create wasted work and delayed timelines. Instead, software developers have long embraced the agile model, which allows for creative and iterative product development cycles.
This leads to a common tension for device software and SaMD: Agile development, while ideal for timelines, costs, and product quality, throws a wrench in FDA documentation. The nonlinear nature of agile development leads many device software teams to leave documentation to the very end of a project once an MVP is complete. Even if the original developer of the application is still involved with the project, it can be difficult to retroactively describe how the technical system was implemented. But even more common, an outside role will be tasked with documenting design and development. Both cases can cause massive amounts of additional work and lead to launch delays.
Having witnessed the challenges connected device and SaMD companies face, the HTD Health team developed a novel process for developing device software that integrates documentation within each agile development cycle or iteration.
Though seemingly at odds, the strategic integration of FDA documentation within agile development allows the team to maintain a creative, iterative approach while ensuring traceability and risk management for compliance with FDA requirements.