Written and maintained by CASRAI Editorial Board
Last updated
AAMI TIR45 (Guidance on the use of agile practices in the development of medical device software) is the Technical Information Report published by the Association for the Advancement of Medical Instrumentation (AAMI) and formally recognized by the U.S. Food and Drug Administration (FDA) that explains how Software as a Medical Device (SaMD) and embedded medical device software teams can execute iterative Agile methodologies (such as Scrum, Kanban, and Continuous Integration) in full compliance with IEC 62304, ISO 13485, and FDA Design Controls (21 CFR § 820.30 / Quality Management System Regulation [QMSR]). Originally issued in 2012 and updated in AAMI TIR45:2023 to incorporate modern DevSecOps, automated CI/CD verification pipelines, and cloud-deployed SaMD lifecycles, TIR45 dispels the misconception that medical device regulations mandate a sequential “Waterfall” development model.
What Is AAMI TIR45 and How Does It Reconcile Agile Software Development with IEC 62304 and FDA Design Controls?
A persistent friction point in regulated digital health engineering arises because IEC 62304 and FDA 21 CFR § 820.30 organize regulatory clauses in a logical sequence—Design and Development Planning, Design Input (Software Requirements), Design Output (Architecture and Detailed Design), Design Verification, Design Validation, and Design Transfer—which quality auditors historically interpreted as requiring 100% of software requirements to be frozen before any code is written. Simultaneously, the 2001 Agile Manifesto prioritizes “working software over comprehensive documentation” and “responding to change over following a plan.”
AAMI TIR45:2023 resolves this apparent conflict by demonstrating that IEC 62304 explicitly permits evolutionary and incremental lifecycle models (IEC 62304 Annex B). Regulations govern the completeness, traceability, and verification of deliverables at the point of formal release, not the chronological order in which tiny increments are drafted during development. AAMI TIR45 structures compliant Agile medical software engineering around three nested lifecycle layers:
- Project / Product Layer: Defines the overarching Software Development Plan (SDP), initial safety classification (Class A, B, or C under IEC 62304), high-level system architecture, and regulatory strategy across the FDA Digital Health Center of Excellence Basic or Enhanced documentation tiers.
- Release Layer: Groups multiple time-boxed sprints into a formal, deployable software version that undergoes end-to-end system verification, clinical/usability validation, ISO 14971 residual risk evaluation, and formal Design Transfer into the Design History File (DHF).
- Increment / Sprint Layer: Executes 1- to 4-week iterations in which a cross-functional team refines user stories into formal software requirements, updates architectural/detailed designs, writes unit and integration tests, performs code reviews, and produces a potentially shippable software increment.
How Do Medical Software Teams Map User Stories, Sprints, and Definition of Done to Formal SRS, SDS, and Traceability Matrices?
In consumer Agile software, user stories written on a Kanban board are often discarded once the code is merged. In regulated medical device development under AAMI TIR45:2023, user stories are workflow vehicles that feed—rather than replace—the enduring Software Requirements Specification (SRS), Software Design Specification (SDS), and Bidirectional Traceability Matrix.
| Agile Practice / Artifact | AAMI TIR45:2023 Regulatory Mapping | IEC 62304 / FDA 21 CFR 820.30 Deliverable Updated |
|---|---|---|
| Product Vision & Epics | Captures clinical intended use, user needs, and system-level capabilities | Design Inputs / User Needs Specification & System Requirements (21 CFR § 820.30(c)) |
| User Story & Acceptance Criteria | Elaborated during backlog refinement into unambiguous, testable functional, performance, security, and interface requirements | Software Requirements Specification (SRS) items (IEC 62304 Clause 5.2) |
| Story Hazard Screening | Evaluates every story during sprint planning for potential clinical hazards, failure modes, or AI model drift risks | ISO 14971 Software Hazard Analysis & Risk Control Measures (IEC 62304 Clause 7) |
| Evolutionary Design & Refactoring | Updates module boundaries, database schemas, and class interfaces incrementally as code evolves | Software Architecture & Detailed Design Specification (SDS) (IEC 62304 Clauses 5.3 & 5.4) |
| Automated CI/CD Test Suite | Executes qualified unit, integration, and regression tests automatically on pull-request merge | Software Unit & Integration Verification Protocols and Reports (IEC 62304 Clauses 5.5–5.7) |
| Multi-Level Definition of Done (DoD) | Enforces mandatory quality gates at Story, Sprint, and Release boundaries before work can be marked complete | Design Review Records & Bidirectional Traceability Matrix (User Need ↔ SRS ↔ SDS ↔ Risk Control ↔ Test) |
The Three-Tier Definition of Done (DoD)
AAMI TIR45:2023 recommends enforcing a formal, auditable Definition of Done (DoD) at three granularities inside Application Lifecycle Management (ALM) tools (such as Jira integrated with Xray/Jama/Polarion/MatrixALM):
- Story DoD: Formal SRS requirement item created/updated; ISO 14971 hazard impact assessed; source code peer-reviewed; static code analysis passed; unit and acceptance tests executed and linked in the ALM traceability graph.
- Sprint DoD: All completed stories satisfy Story DoD; automated integration and regression test suite passes on the staging build; Software Architecture/SDS documentation updated to reflect any refactoring performed during the sprint; Sprint Review recorded.
- Release DoD: Full system-level verification executed against a locked release candidate commit hash; all unresolved anomalies (bugs) evaluated for clinical risk; Cybersecurity SBOM (Software Bill of Materials) and SOUP (Software of Unknown Provenance) audits finalized; formal Design Review signed off in the DHF.
When Must Formal Design Freeze and Verification Occur in an AAMI TIR45 Agile Release Cadence?
While AAMI TIR45 allows requirements, architecture, and code to evolve fluidly across development sprints, a medical device software version cannot be released to clinical production or submitted for FDA artificial intelligence / SaMD marketing authorization without a formal Design Freeze and Release Hardening phase.
Before a Release Candidate is deployed to patients or clinical trial sites, the engineering team freezes the Git release branch (establishing a cryptographic configuration baseline under IEC 62304 Clause 8). Any verification evidence relied upon for regulatory release must either be executed after this design freeze on the final release build, or—if leveraging continuous verification results accumulated during earlier sprints—must be supported by documented regression impact analysis and automated continuous integration (CI) regression runs proving that subsequent sprints did not invalidate the earlier test results.
Frequently Asked Questions
What is AAMI TIR45 and how does it reconcile Agile software development with IEC 62304 and FDA Design Controls?
AAMI TIR45:2023 is an FDA-recognized consensus Technical Information Report that shows medical device and SaMD teams how to run iterative Agile sprints by generating regulatory deliverables (requirements, architecture, risk controls, and verification tests) incrementally each sprint rather than in a single Waterfall sequence.
How do medical software teams map user stories, sprints, and Definition of Done to formal SRS, SDS, and traceability matrices?
Under AAMI TIR45, user stories and acceptance criteria are refined into formal Software Requirements Specification (SRS) items inside an ALM tool, paired with ISO 14971 risk assessments and SDS design updates, and governed by a three-tier Definition of Done (Story, Sprint, and Release) that maintains live bidirectional traceability from user needs to automated test results.
When must formal design freeze and verification occur in an AAMI TIR45 Agile release cadence?
Formal design freeze must occur at the Release boundary before clinical deployment or FDA submission: the release candidate branch is locked under configuration management, full regression verification and anomaly risk reviews are completed against the frozen baseline, and formal Design Transfer sign-off is recorded in the Design History File.
