TIR45 and Agile in Medical Device Software Development: Should Your Organization Adopt It?
As the medical device industry continues to evolve toward software-defined innovation—particularly in the realms of Software as a Medical Device (SaMD) and connected health technologies—the question facing many regulatory and engineering leaders is no longer if they should modernize their development approach, but how to do so without compromising compliance.
One guidance document gaining traction is AAMI TIR45:2012 – Guidance on the use of Agile practices in the development of medical device software. While not a normative standard, TIR45 offers practical insight into the implementation of Agile methodologies in regulated environments, specifically in alignment with frameworks such as IEC 62304 and ISO 13485.
This article explores the strategic relevance of TIR45 for organizations—particularly those in early-stage or growth-phase development—and assesses whether adopting it will enhance or hinder your regulatory posture.
Understanding the Role of TIR45
TIR45 is a Technical Information Report, which means it is a consensus-based publication intended to supplement—not replace—formal standards. Published by AAMI, it addresses a persistent tension in the industry: reconciling Agile software development methodologies with the stringent lifecycle and documentation requirements mandated by global regulatory bodies.
TIR45 acknowledges the reality that many medical device firms, especially those building SaMD or incorporating machine learning components, rely heavily on iterative development, continuous deployment pipelines, and modular codebases. Rather than prescribing rigid processes, it provides structured guidance on how Agile can be harmonized with a regulated quality management system.
It is particularly useful for aligning Agile practices with:
- IEC 62304 (software lifecycle processes),
- ISO 14971 (risk management),
- ISO 13485 (quality management systems).
Key Themes and Contributions of TIR45
Rather than offering a prescriptive checklist, TIR45 articulates principles and implementation strategies to ensure Agile teams meet the expectations of regulators without abandoning modern engineering practices. Notable areas of guidance include:
1. Organizational Role Mapping
TIR45 provides recommendations for mapping Agile team roles to quality and regulatory responsibilities. It clarifies how the roles of Scrum Master, Product Owner, and development team members can be integrated into a quality system that emphasizes accountability, documentation, and traceability.
2. User Stories and Requirements Engineering
Agile user stories, when adequately structured with clear acceptance criteria, can fulfill the function of software requirements specifications (SRS). TIR45 offers guidance on how to decompose epics into verifiable units of work and link them to risk controls and verification activities.
3. Risk Management Integration
The report stresses the importance of embedding risk-based thinking into Agile processes. This includes conducting impact assessments during backlog grooming, incorporating risk controls into sprint deliverables, and linking testing artifacts to hazard mitigations.
4. Design Control Within Iterative Frameworks
One of the most valuable contributions of TIR45 is its articulation of how to conduct design reviews, configuration management, and change control within the context of sprints and releases. It emphasizes the need for robust criteria for “done” and suggests that Agile cadences can in fact improve early detection of design deficiencies.
5. Traceability Strategies
While Agile is sometimes perceived as lightweight or informal, TIR45 provides examples of how modern toolchains (e.g., Jira, GitLab, Azure DevOps) can be configured to ensure full bidirectional traceability—from requirements to verification—without introducing unnecessary manual overhead.
How TIR45 Complements IEC 62304
Where IEC 62304 defines the required outputs and documentation across the software lifecycle, TIR45 offers guidance on how to generate and manage those outputs within an Agile context.
| IEC 62304 Requirement | Agile-Compatible Approach (per TIR45) |
|---|---|
| Software Development Plan | Living plan with sprint-based roadmaps and release maps |
| Software Requirements | User stories + acceptance criteria integrated with risks |
| Software Architecture | Modular epics mapped to design outputs |
| Unit and Integration Testing | Test-driven development; CI/CD pipeline integration |
| Configuration Management | Git-based source control with automated traceability |
This mapping is especially critical for organizations seeking to accelerate time-to-market without jeopardizing submission readiness or post-market audit preparedness.
Agile to IEC 62304 Mapping Guide
This guide shows how common Agile development artifacts can be mapped directly to the required deliverables outlined in IEC 62304. It’s designed to help teams working in regulated environments translate iterative Agile workflows into compliant documentation and traceability structures. The mappings below include references to specific IEC 62304 clauses, detailed rationale, and implementation tips. This structure follows the guidance provided in AAMI TIR45:2012, which outlines how Agile can be used effectively in medical device software development when traceability, risk management, and documentation controls are properly managed.
| Agile Artifact | IEC 62304 Deliverable | IEC 62304 Clause(s) | Mapping Rationale & Implementation Considerations |
|---|---|---|---|
| User Story | Software Requirements Specification (SRS) | 5.2.2, 5.2.3 | User stories, when written with clear acceptance criteria and linked to risk mitigations, satisfy the definition of functional and non-functional software requirements. For audit purposes, user stories should be version-controlled, reviewed, and traced to design outputs and verification activities via a traceability matrix. Tooling (e.g., Jira, Azure DevOps) should include custom fields for risk linkage and trace status to meet documentation expectations. |
| Epic | Software Architecture Design | 5.3.1, 5.3.3 | Epics represent broad functional capabilities or architectural modules. These can be decomposed into software items and components as required by clause 5.3.1. Ensure that epics are supported by architectural diagrams, interface definitions, and modular decomposition in your design documentation. Maintain version-controlled design records for each architectural layer to meet 62304 expectations. |
| Sprint Increment | Detailed Design & Implementation Output | 5.4.1, 5.5.1, 5.5.2 | Each sprint cycle produces an increment of code tied to implemented design. Ensure that all code is committed through a controlled repository, with review history, unit test records, and design annotations. Sprint planning documentation should specify which backlog items correspond to which design outputs and include rationale for test coverage. This traceability ensures compliance with clauses covering software construction and detailed design traceability. |
| Test Case | Verification Procedures and Results | 5.6.1, 5.6.2 | Test cases—automated or manual—must demonstrate that each software requirement has been verified. They should also trace back to risk controls where applicable. Store test results, logs, and summaries in a centralized, version-controlled repository with sufficient metadata (e.g., tester name, environment, execution timestamp). Consider adding pass/fail criteria tied directly to the acceptance criteria of user stories to align with clause 5.6.2’s verification evidence requirements. |
| Backlog Item / Change Request | Change Control Record / Software Maintenance Plan | 6.1, 6.2, 6.3.2 | Backlog items that involve defect correction, improvements, or feature extensions should be classified as change requests. These must follow formal change control procedures per clause 6.1 and be justified through documented review. Link backlog IDs to CAPA records where applicable. Ensure changes are evaluated for potential impact on previously verified software, and that regression testing is planned and documented accordingly. Maintenance plans should include a backlog management SOP aligned to these clauses. |
Why TIR45 Is Especially Relevant for Emerging Organizations
For companies in their early stages—particularly those developing SaMD, AI-enabled tools, or digital therapeutics—TIR45 offers several key advantages:
- Regulatory Efficiency: By embedding regulatory thinking into Agile ceremonies, you reduce the rework commonly associated with last-minute documentation efforts.
- Risk-Aligned Innovation: Agile enables faster iteration, but without structured controls, it can introduce latent design risks. TIR45 provides a pathway to balance velocity with risk mitigation.
- Scalability: Organizations that adopt TIR45 from the outset are often better positioned to scale their QMS and development processes without disruption.
- Regulatory Credibility: Referencing TIR45 in your SOPs, design history files (DHFs), and submissions demonstrates a commitment to recognized best practices—even in the absence of a mandated standard.
Implementation Considerations
Organizations should take a deliberate approach when implementing TIR45. Below are four foundational steps to ensure successful adoption:
1. Align Your Quality System
Integrate TIR45 principles into your development SOPs. Establish clear definitions for Agile artifacts and explicitly map them to required outputs under IEC 62304.
2. Train Cross-Functional Teams
Your development team must understand the regulatory implications of their workflows, and your quality team must understand how Agile works in practice. A shared vocabulary is critical.
3. Select the Right Tools
Choose a software toolchain that supports traceability, version control, automated testing, and audit logs. Configure these tools to align with regulatory outputs—not just developer convenience.
4. Establish Traceability Protocols
Create a trace matrix that links backlog items to design inputs, risk mitigations, test cases, and verification records. Ensure this matrix is continuously maintained through sprints and releases.
Common Pitfalls to Avoid
| Challenge | Impact |
|---|---|
| Informal or undocumented Agile workflows | Insufficient evidence during audits |
| Misalignment between QMS and Agile practices | Gaps in traceability, risk coverage, or change control |
| Tool reliance without process governance | Automated chaos—volume of data without regulatory value |
| Lack of internal training | Miscommunication between QA, RA, and R&D |
TIR45 is not a shortcut. It is a framework that demands intentional design, cultural alignment, and disciplined execution.
Final Analysis: Is TIR45 the Right Fit for Your Organization?
TIR45 is best suited for organizations that:
- Develop software-based or software-heavy medical devices.
- Employ Agile or plan to move toward iterative development.
- Seek to establish a scalable, auditable, and modern software development process.
- Are in early growth phases and want to embed compliance into product development—not bolt it on after the fact.
TIR45 is not a substitute for IEC 62304, nor does it eliminate the need for traditional quality documentation. However, it is a powerful implementation guide that enables organizations to move quickly without sacrificing regulatory credibility.
Closing Thoughts
The regulatory landscape for digital health is evolving rapidly. Organizations that succeed will not be those that simply follow legacy procedures, but those that can sustain compliance while accelerating innovation.
TIR45, when properly implemented, provides a pathway to do exactly that.
If your organization is building a quality system from the ground up—or adapting legacy processes to support modern development—it is worth taking a serious look at integrating TIR45 into your approach.