Contact us
FDA regulated software
compliant development
Back to Insights


How does FDA documentation fit into agile development?

Share the article

Sep 17, 2020

6 min read

HTD’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:

  • 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.

The immense potential of connected devices does not come without strict guidelines and resulting in development challenges. Understanding the 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 the 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


Free consultation

Still have questions? Reach out to our SaMD expert and chat

We will develop an executive plan for your medical device software

Contact Us

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.

SaMD market segments

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.

Phase 1: Concept of Operations

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

Phase 2: Requirements and Architecture

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

Phase 3: Implementation Loop

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.

Phase 4: System Validation and Verification

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)

Phase 5: Operation and Maintenance

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.

Other content you may be interested in

View all articles

Aug 10, 2023

8 min read


Understanding FDA software guidance for AI medical devices

Read more
New FDA guidance

May 31, 2023

5 min read


FDA cybersecurity guidance: New law all SaMD manufacturers must follow

Read more

Apr 18, 2024


3 Critical Steps for Efficient Medical Device Software Development

Read more