How to Build Medical Device Software: Aligning Agile with FDA Guidelines

Historically, the FDA’s focus was mostly on hardware-based devices. But now that software is often the “device” itself—Software as a Medical Device (SaMD)—the rules have had to evolve.

The International Medical Device Regulators Forum (IMDRF) has helped define how these new kinds of devices fit into the existing system. In the U.S., the FDA uses a concept called “Level of Concern” to help developers understand the amount of documentation required. This depends on the potential risk the software poses if it fails or malfunctions.

Here’s a general breakdown of what the FDA looks for:

• What the device is and what it does
• How the design was implemented
• How the software was tested
• What risks exist and how you’ve addressed them
• A clear trace between requirements, design, testing, and risk mitigation

One of the most important standards you’ll hear about is IEC 62304. This is the international standard that outlines the software lifecycle processes for medical devices. It’s the blueprint for how to build safe, functional software in a way that meets regulatory expectations.

A few key terms to know from IEC 62304:

• Software Safety Classification: Similar to the FDA’s Level of Concern, this classifies software as A, B, or C depending on risk. Class A is low risk; Class C is high risk.
• SOUP: This stands for Software of Unknown Provenance—basically, third-party libraries or open-source tools. If you’re using them, you’ll need to document how you’ve evaluated and tested them.
• Traceability: You need to be able to trace each requirement through the code, tests, and risk analysis.

The standard doesn’t tell you how to code—it tells you how to manage the process around building and maintaining that code. That’s where the tension with agile development often shows up.

Developers coming from other regulated fields like finance or aerospace might assume the rules are the same across the board. But medical device regulation is unique. For instance:

• Timelines tend to be longer in MedTech, especially if the device needs FDA clearance.
• Risk classification has more direct patient impact—if a banking app fails, it’s frustrating. If a glucose monitor fails, it’s a medical emergency.
• Post-market requirements are different too—there are expectations for ongoing safety monitoring, not just launch-readiness.

That’s why having a framework tailored to medical device development is so important.

Building software for medical devices means working within strict FDA documentation requirements. Historically, that’s pushed many companies toward a waterfall development model. In waterfall, you define everything up front—requirements, architecture, testing plans—and then move step by step until the product is complete.

That may work fine for hardware, but in software development, waterfall often leads to delays, rework, and surprises at the worst time: the end. If a requirement changes halfway through—or worse, if you discover something new through user testing—you’re stuck trying to somehow make it work after the fact. Developers have long favored agile approaches for this reason: build a little, test it, learn something, improve it, and repeat.

But here’s the problem: Agile and FDA documentation don’t always play nicely together. The flexible, looped structure of agile can clash with documentation expectations that want a clear, linear story. Too often, documentation gets pushed to the end of the project. That creates two big risks:

1. You forget why certain decisions were made or how they were implemented.
2. Someone who wasn’t part of the build has to write the documentation, often retroactively.

Both situations mean more work, more stress, and slower timelines.

At the heart of our approach is HTD’s Compliant Agile Development methodology—a framework that bridges the tension between regulatory requirements and modern software development practices:

• Regulatory pathways often force teams toward waterfall development:
  • Documentation expectations favor upfront comprehensive requirements
  • Linear phase-gate processes discourage iterative development
  • Risk documentation traditionally occurs at specific milestones
• But Agile is essential for SaMD success:
  • Enables rapid prototype iterations based on clinical feedback
  • Reduces time-to-market while maintaining quality
  • Creates more intuitive, user-centered software interfaces

Through Weronika Michaluk’s leadership of our MedTech Practice, HTD has pioneered a different pathway—Compliant Agile Development—that harmonizes these opposing forces. This methodology preserves the innovation speed and user feedback loops critical to software excellence while systematically addressing regulatory requirements.

Our framework integrates IEC 62304 standard requirements with Agile Development methodologies through a layered approach that operates across multiple levels:

• Product Level: High-level requirements analysis, and architectural infrastructure design
• Release Level: Release-specific planning, integration and system testing across release
• Iteration/Sprint Level: Sprint planning, feature development, and testing within sprints
• User Story Level: Story-specific implementation with appropriate documentation

This structured yet flexible approach allows us to:

1. Integrate documentation throughout development: Rather than leaving documentation to the end, we integrate it throughout the development process
2. Implement continuous risk management: Risk analysis and mitigation are performed throughout the entire development lifecycle, with special attention to high-risk components
3. Enable rapid iteration: The framework supports fast development cycles while ensuring regulatory requirements are addressed

We make documentation easier by:

• Automating parts of the process using tools that track changes, test results, and requirements
• Updating documentation after every sprint, not just at the end
• Mapping work directly to what regulators expect, such as FDA or IEC 62304 requirements

For example, traceability matrices are updated automatically based on Git commits. Risk assessments are reviewed regularly, and tools like Jira and Confluence are structured so that documentation follows the progress of actual development work.

To make this work, structure matters. HTD uses cross-functional teams that include not just designers and developers, but also people with compliance and regulatory expertise. We also use a Guild model—a structure where experts in areas like quality, testing, and compliance work across teams to share best practices and guide decision-making.

In addition, we run training programs to help every team member understand the role of compliance in their work. Developers don’t need to be regulatory experts, but they do need to know how their code and decisions affect documentation, risk, and audit readiness.

Our development environment is also set up for compliance from the start. That includes:

• Version-controlled documentation that matches code changes
• Automated compliance checks built into CI/CD pipelines
• Tools that connect design, testing, and risk workflows in one place

We also apply a compliance information architecture that helps organize documentation, data, and review processes so that auditors (and internal teams) can easily find what they need.

HTD’s Compliant Agile framework is built around five key phases. These phases mirror the structure of the traditional V-model used in medical device development but are adapted to support agile, iterative work cycles. Each phase includes built-in FDA documentation requirements and continuous updates as development evolves.

This is the foundation of the project. At this stage, we define what the software should do, who it’s for, and how it fits into a broader business and clinical context. We also begin risk assessment and document early regulatory assumptions.

Documentation includes:

• Software description
• Preliminary FDA level of concern classification
• Initial hazard analysis

Once the core idea is defined, the team builds out more detailed requirements and maps them to an early product architecture. Agile user stories begin to shape the development backlog. Documentation becomes more structured here and supports both system understanding and regulatory review.

Documentation includes:

• Software Requirements Specification (SRS)
• Architecture and design diagrams
• Traceability matrix linking risks and requirements
• Description of development and testing environments
• Initial validation and verification (V&V) planning

This is where the traditional V-model is extended. Instead of one long implementation phase, we use agile sprints to iteratively build and refine the product. Each sprint results in new or updated documentation—capturing how the system has changed, what was tested, and any new risks introduced.

Documentation includes:

• Software Design Specification (SDS)
• Sprint-level change logs with traceability flags
• Screen-level designs (if required by risk level)
• Updates to SRS, SDS, hazard analysis, and architecture as needed

Documentation is maintained alongside code, making it easy to review what changed, why it changed, and how it was verified.

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 features have been implemented and refined through sprints, the system is tested as a whole. System-level testing checks that the software meets all documented requirements and is ready for FDA review.

Documentation includes:

• Verification and Validation (V&V) test results
• Summary of any unresolved issues or known limitations
• Updates to the traceability matrix confirming test coverage

HTD also supports parallel independent testing at this phase when required, including usability studies or third-party verification.

After FDA clearance, the software moves into ongoing maintenance. This includes monitoring performance, resolving bugs, and capturing input for future versions. Risk management continues in this phase, especially as the software interacts with real-world data and feedback.

Documentation includes:

• Issue and anomaly logs
• Post-market surveillance reports
• Documentation updates tied to any patches or updates
• Roadmapping inputs for future releases

Process validation is a core requirement in FDA-regulated environments, especially for medical devices and Software as a Medical Device (SaMD). It ensures that your development process consistently produces a product that meets its intended use and safety requirements.

In traditional waterfall models, verification and validation (V&V) are treated as final steps. But for agile teams building regulated software, this approach is too risky. That’s why HTD’s Compliant Agile framework integrates V&V into every phase of development—enabling continuous validation and faster compliance under FDA process validation guidance.

We begin thinking about testability during the requirements and architecture phase—not just what needs to be built, but how we’ll know it works. By planning for validation early, we’re not scrambling to write test cases after the fact.

Examples:

• Each user story includes test acceptance criteria
• Risks identified in the hazard analysis are mapped to validation test cases
• Code changes automatically trigger targeted test plans

To stay agile while meeting FDA expectations, we use automation wherever it makes sense. This includes:

• Unit tests run during development
• Integration tests executed in CI/CD pipelines
• Automated generation of validation documentation from test results

This setup helps us test early, test often, and prove traceability without extra overhead.

In high-risk software (or where required by the FDA), we also support independent validation—often in parallel with internal work. For example:

• A separate QA team may review V&V documentation and test results
• Usability testing may run alongside final system verification
• External clinical consultants may validate functional safety requirements

This dual-path strategy allows for fast feedback while keeping quality and compliance front and center.

To improve over time, we track and review metrics specific to V&V performance:

• Defect density per sprint
• Test coverage mapped to software risks
• Number of unresolved anomalies at each release
• Time from code completion to verified output

These indicators help us spot gaps early and keep the process running smoothly—without sacrificing regulatory readiness.

Medical device software requires both speed and rigor. HTD’s Compliant Agile Framework enables agile teams to move quickly while meeting the demands of FDA and international regulators. With the right structure, tooling, and training, it’s possible to build great software—safely and compliantly.

HTD has applied this methodology across a range of products, including:

• Software as a Medical Device (SaMD)
• Connected hardware devices
• Digital therapeutics and behavior change apps
• EHR-integrated tools and clinical platforms
• Pharma companion apps and devices

It’s flexible enough to support both early-stage startups and large enterprise teams scaling regulated platforms.

If you’re looking to bring a regulated product to market (or modernize your existing development process), HTD’s Proven Methodologies can help you get there faster, with confidence.