The TIR45 (“Guidance on the use of AGILE practices in the development of medical device software”) is a Technical Information Report (hence TIR) of AAMI, the Association for the Advancement of Medical Instrumentation.
First published in 2012, TIR45 has one primary objective: To guide medical device manufacturers on developing software compliant with FDA requirements while using agile practices, specifically those in the guidance documents. The Technical Report also focuses on IEC 62304.
Read a compact summary here.
1. Key statements of the TIR 45
The TIR45 says that it is possible to develop software for medical devices using agile software development practices while being compliant with regulatory requirements.
a) Advantages of agile development
The report sees the advantages of agile development as:
- High focus on safety and customer satisfaction by reprioritizing the backlog and incorporating customer feedback.
- Good estimation of quality through continuous testing.
- Continuous improvement of the development process through retrospectives.
- QM requirements are met because there is a clear definition of done.
Interestingly, TIR 45 does not mention the ability to adapt to constantly changing customer requirements as an advantage. We have repeatedly warned against the misuse of agility to determine stakeholder requirements iteratively.
b) Challenges
The report considers the fact, perhaps even the temptation, to be able to make changes to the software quickly in an agile model a challenge.
c) Requirements
The TIR 45 specifies requirements that must be met to comply with the regulatory requirements:
- The development must take place under the framework of a QM system. The agile approach must not lead to a violation of the requirements mentioned there.
- A development life cycle must be defined. In one place, it also says, “Augment the discipline of necessary robust processes and tools,” in another “Set the correct expectations by defining the software development lifecycle model”.
- Effective change management must be established because the temptation to make changes to the software quickly (the value proposition of agile development) must not result in poor product quality and increased risks.
- The documentation must meet the requirements of the development team and the regulations.
d) Version 2023
2023 AAMI has updated the TIR 45. The changes are not revolutionary. Besides a reorganisation of some contents, there is an update of the regulatory references and new chapters on agile practices.
2. Scope of application of TIR 45
a) Regulations considered
The authors of TIR 45 (“Guidance on the use of AGILE practices in the development of medical device software”) considered the following regulations in writing it:
- ISO 13485:2016
- IEC 62304:2006 + AMD1:2015
- ISO 14971:2019
- FDA 21 CFR 820
- FDA “Guidance for the content of premarket submissions for software contained in medical devices”
- FDA Guidance “General principles of software validation”
b) Target group
The TIR 45 is aimed at
- medical device manufacturers
- software development teams
- people who specify requirements for software
- project and quality managers
- regulatory affairs staff
- external and internal auditors
- notified bodies and authorities
3. Implementation of agile development for medical devices according to TIR 45
a) The layers
The TIR distinguishes different iteration loops: “layers”.
| Layer | Development outputs | Duration |
| Project/Product | Finished device | Months, a year, or longer |
| Release | Finished device or product (version) for internal testing | One to several months |
| Increment | Set of functionalities, not necessarily complete software system | One to four weeks |
| Story | Functionality or partial functionality | One to a few days |
b) Layers and activities
For each layer, the TIR45 provides certain activities for which it refers to the numbering according to IEC 62304.
| Layer → ↓ Activity | Project | Release | Increment | Story |
| 5.1 Planning | X | X | X | X |
| 5.2 Software requirements | X („high level“) | X | ||
| 5.3 Software architecture | X Coarse architecture | X | ||
| 5.4 Detailed design | X | |||
| 5.5 Implementation | X | |||
| 5.6 Integration test | on release | X | X | X |
| 5.7 System test | on release | X | X | X |
| 5.8 Release | X |
4. Design inputs, design outputs, design reviews
The regulations require documented design inputs and design outputs. The TIR45 provides guidance on how artifacts can be divided between these two groups. It also makes clear that in an agile environment, there is not an initial large set of design inputs, but design inputs and design outputs, which even influence each other, are continuously generated. Design inputs and outputs are generated in pairs in large numbers. The TIR 45 sees the story as a framework for one of each of these pairs.
Further, the TIR4 5 sees the end of increments and releases as times for design reviews but recommends using the software development plan to define which of those reviews are formal design reviews as required by the QM systems.
a) Design inputs
Among the design inputs, the TIR 45 includes the user stories with their associated acceptance criteria, which must include non-functional aspects.
b) Design outputs
Consequently, all other artifacts would have to count as design outputs such as
- architecture and detailed design
- code
- test specifications and test results
5. Evaluation by the Johner Institute
The Johner Institute endorses the use of agile development practices – also in the regulated medical device context. We have gained the following insights from many consulting projects:
Advantages
- An early and stable architecture (“Upfront”), as suggested by TIR 45, is highly recommended.
- Regular retrospectives lead to continuous learning and sometimes to an improvement of the documented process.
- Time-boxing and a higher level of automation of tests increase software quality.
- The “Definition of Done” leads to better and more compliant development documentation if it includes the documentation aspects.
Disadvantages
- Too large gap between project and user story: Breaking down both the architecture and high-level requirements to the story level often leads to problems. Both should at least be further detailed at the release level as well.
- Many manufacturers find it challenging to comply with the request of an auditor or inspector to show the consolidated software requirements. TIR 45 gives the (conditionally helpful) tip: “Define how documentation is written, controlled, and approved as a sum of its parts.”
- The releases of changes that become necessary at the level of increments or stories and that affect the software system as a whole (in the V-model, one would speak of setbacks) are not clearly regulated or are not adhered to.
- Development planning is updated (and sometimes even followed) more carelessly the further one moves from the project level toward the story level.
- The (too) late determination of detailed software requirements, especially for “non-standalone software,” leads to these requirements being determined by the development team and not to a sufficient degree by usability and requirements engineers, resulting in suboptimal user interfaces. Unnecessary iterations are the result.
- The regulatory requirements for keeping available a consistent technical documentation (>10years) for products placed on the market can be more challenging.
The Johner Institute supports medical device manufacturers in designing agile and standards-compliant development processes.
Change history
- 2023-06-16: Added references to version 2023; editorial changes
- 2016-03-23: First version published
