All Articles
Insight of the week
Development

Introducing Compliant Agile

HTD Health’s novel approach to building compliant medical device software

Piotr Lewandowski

Piotr Lewandowski

• 6 min read

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:

  • Collecting reliable, consistent data from a particular patient over time or a cohort of patients with similar conditions.
  • Improving user engagement and empowering patients to understand their own health behaviors and outcomes.
  • Allowing for remote monitoring of chronic conditions and fewer in-person appointments.
  • Flagging worrisome changes in patient data for rapid emergency response and improving the accuracy of diagnosis.

Sign up for the HTD Insights Newsletter

Healthtech research, news, and industry-defining trends delivered to your inbox monthly.

We respect your privacy. This email address will only be used to send HTD’s Insights newsletter. Click here to review our full privacy policy.

Thank you for subscribing!

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:

  • A description of device design
  • Documentation of how device design was implemented
  • Demonstration of how the device software was tested
  • Identification and mitigation of risks or hazards posed by device software
  • Traceability across design, implementation, testing, and risk management

Don’t go chasing waterfall

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.

Compliant Agile

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.