Agile medical device teams used to be rare.
Back in 2011, venture capitalist Marc Andreessen declared, “software is eating the world,” setting forth a then-radical idea that software programming tools and internet-based weren’t just catalysts for countless industries — they were here to stay. A decade later, it’s safe to say the life science industry has become nearly entirely software-driven. From personal health apps to surgical robots and AI diagnostics, software developers are joining MedTech companies in droves, bringing another culture with them.
The medical device industry is going Agile, big time.
This article is written for both newcomer software devs and grizzled veterans. Regardless of your experience, creating medical device software using an Agile process is a high-skill practice that requires you to get out of your comfort zone.We’ll discuss here the waterfall model, Agile methodology, and design controls. And we’ll also talk about release cadence because that’s why all of this matters.
Basic definitions and the core conflict
Waterfall, the logical progression of steps through the software development process, is how medical devices were traditionally developed. And it’s how software is still produced in many places today —which makes it a giant shadow that hangs above anyone who tries to do things more agile.
Agile, a people-focused methodology that emphasizes progress over perfection, is a promise for a better future with less wasteful processes and quicker times to market.
Design controls are the regulatory requirements imposed on medical devices’ development process. This includes requirements such as release documentation, traceability matrices, test coverage, etc.
Design controls are non-negotiable. The scope and extent of reviews, testing, and documentation vary based on the device you are building. Assuming you have a skilled regulatory expert, the list they specify for your team should be regarded as an integral part of your deliverables. After all, software created without the design controls has zero value. Doctors or patients can’t use it, nor can it be sold.
The Agile Manifesto calls for “working software over comprehensive documentation,” which presents core friction. Design controls require comprehensive documentation, and this can’t be avoided. The sooner you embrace this fact, the quicker you will be able to “just get on with the job” and create an “Agile-ish” process that complies with design controls requirements.
From waterfall to Agile, why “emerging” is the key term
Historically, the waterfall model was the FDA’s primary example of how to design medical devices and has become the de-facto standard process since its introduction in the previous century.
The core idea of this methodology is that you elaborate and approve the high-level requirements (user needs) before you move to technical specifications (design inputs). When the implementation work is complete, you run a full test cycle. Finally, once all tests are completed successfully and documented, the device can be released.
Downfalls of the waterfall methodology
Let’s say you’re developing a sophisticated app to analyze X-ray images for bone fractures.
The waterfall process dictates that all the user needs are approved before you even start drawing the wireframes for the interface. Everything from the platforms the software will run on to the type of input it will expect, the output principles, and how the user will access the device must be agreed on before further defining the system architecture or the UX.
This process reveals the most significant issue with using the waterfall model for medical device development: it doesn’t allow for experimentation, iteration, and adaptation of the requirements as a response to the engineering work and the evolving business environment.
Further, most medical device software developers want to proceed with conceptual wireframing and devising critical functionality once there’s agreement on the key use case for the device. In the X-ray app example, as soon as the image processing algorithm is solidified and the type of images the device will process is agreed upon, the app development could proceed in some areas (i.e., the input processing and visualizations). Ideally, this all happens even if some aspects of the user needs —like the authentication — aren’t even discussed, never mind approved.
The Waterfall model makes much more sense in traditional hardware projects and clearly is not a fit for how modern software teams want to work.
An Agile-ish solution for the MedTech industry
Happily, the Association for the Advancement of Medical Instrumentation (AAMI) commissioned the AAMI:TIR 45: “Guidance on the use of AGILE practices in the development of medical device software,” which was created by a committee of industry leaders and endorsed by the US FDA. Today, it’s the guiding light that explains how Agile is, in fact, compatible with the regulatory requirements that MedTech software developers are expected to meet.
The following are the fundamental principles of the guidance:
- To comply with design controls, you must fully document user needs, design inputs, design process, and design outputs.
- You can do that in an emerging manner (rather than sequentially).
What this means in practice:
- First, when you have some vague idea of what your users need, add the specifications to your list of user needs.
- Then you can create the technical specifications (design inputs) to the extent that you understand them at this stage.
- You can also create stories to implement those design inputs so that the implementation work can be kicked off.
- The story is defined as DONE only when:
- The tests for the new features are specified; this lays the groundwork for the pre-release test cycle.
- The design input is reviewed and, once completed, is corrected to reflect the actual implementation as realized by the story.
- The story is defined as DONE only when:
This means that all the design controls deliverables are constantly emerging in synchronization with each other. As you progress with the deployment of the device, each iteration will have all the supporting documentation ready for release.
As soon as there is a scope that is valuable for users, the device can be released. And going forward, improvements can be frequently delivered to the market, as appropriate.
Ongoing iteration is probably the biggest advantage of all. While delivering the first version of a new device is always a significant undertaking, having a process that allows you to deliver frequent incremental improvements is where the Agile process really earns its keep. Your team becomes nimble, quickly reacting to real-time feedback received from users.
Where to start?
In summary, when using the Agile methodology to design and deploy a medical device:
- Embrace the fact that you’ll need to create detailed design controls documentation.
- Include the refinement/alignment of the design controls in your Definition Of Done (DoD); If you are working in Agile squads, include someone who can create the design controls documentation.
- Get into the flow with the emerging nature of your device.
Once you have mastered the above, the next phase is to evolve your DevOps practice. Automatic tests and a continuous integration cycle will be very helpful in releasing often. But that’s getting ahead of ourselves — for now, you have the details of how the Agile process plays out in the medical devices space. If you have questions, don’t hesitate to ask us —we’re here to help!
