How does FDA documentation fit into agile development?

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.

The diagram above illustrates HTD’s Compliant Agile process. The structure of the diagram draws from the well-established V-model development framework, but differs in implementation where we have built in a repeating series of agile sprints.

The development process calls for five phases, each informed by a fundamental analysis:

1. Concept of operations
2. Requirements and Architecture
3. Implementation Loop
4. System Validation and Verification
5. Operation and Maintenance

FDA documentation is built into each phase and continuously updated as requirements evolve during the agile implementation loop. As documentation differs slightly by level of concern or risk, this model can adapt to meet the specific FDA recommendations associated with a particular product.

The first phase of the process consists of a high-level product concept informed by fundamental analysis. What are the high-level goals of the software from both a business and user perspective? Documentation at this stage includes:

• Software description
• Initial categorization of the FDA level of concern
• Device Hazard Analysis

The second phase of the process involves product requirements at a more detailed level. User stories guide team members in creating product architecture and a backlog of design and development tasks. Documentation at this stage varies according to device class and whether or not predicate devices exist, but typically includes:

• Software Requirement Specifications (SRS)
• Architecture design chart
• Traceability analysis
• Software development environment description
• High-level description of the Verification & Validation (V&V) requirements

Where this model departs from a traditional V-model development process is in the implementation phase. Rather than implementing requirements and architecture one time according to decisions made at the start of the project, HTD’s “Implementation Loop” stage serves as an agile development process within the larger V-model. This means that implementation itself is repeatable as needed to allow for iterative improvement and in each subsequent iteration, the team follows a rigorous process of building, verifying, and testing software components to produce necessary FDA documentation and maintain a high level of quality. With clear, traceable documentation of the iterative implementation process, the team can easily add necessary updates to earlier concept and requirements documentation when needed.

Documentation at this stage includes:

• Software Design Specification (SDS)
• Revision level history with flags to any prior documentation that may have been affected by agile changes
• Additional detailed screen-by-screen designs (only if required by the level of concern)
• Updates to all phase 1 and 2 documentation that may have been affected including new hazards, changes to the SDS or SRS, etc.

The process of flagging system changes at the end of each sprint and tracing said changes back to prior documentation is what allows the team to continually document along with the agile development process.

Once the agile implementation loop has allowed the team to implement, test, and iterate on each feature, the software is then tested at a system level. Once system-wide testing is complete and any necessary adjustments have been made, client stakeholders can submit the software for FDA approval. Documentation at this stage includes:

• Verification and Validation Documentation (V&V)
• Identification of unresolved anomalies (bugs or defects)

Once cleared by the FDA, SaMD systems can move into operation. During this time, the team works continuously to resolve any remaining bugs or edge cases while also compiling and scoping customer requests and client R&D outcomes to inform the next product version.

The tooling ecosystem is evolving quickly with players such as Jira, Confluence, Enzyme, and Greenlight Guru combining the power of ticketing and knowledge management. These tools centralize user stories and product requirements and tie them to verification testing and risk management. With each change made through the iterative Implementation Loop, design specifications can be updated in one location and automatically applied across all impacted system features. Verification testing can also become increasingly automated so that with each iteration, the team can easily flag bugs or issues before integrating with other features. These solutions also offer the ability to track and visualize progress against KPIs to identify areas of opportunity to increase efficiency and improve processes. When the system-wide Verification and Validation phase is complete, all up-to-date documentation from all project phases can be exported for submission to the FDA.