I believe in starting an Agile roadmap from an agnostic Agile perspective. I focus on the outcomes. I focus on flow. I focus on learning. I do this in any industry. I do it even more in safety-critical industries.
That is why I paid close attention to the updates in AAMI TIR45:2023.
This update matters. It gives regulated teams a clearer path. It also reduces friction with regulators. In practice, it can mean fewer questions from FDA. It can mean fewer surprises late in the program.
Key Takeaway: TIR45:2023 reinforces incremental compliance and discusses how to work with other areas that may not be agile within your QMS. It ensure your team understand that they should produce objective evidence continuously rather than pushing “documentation and approvals” to the end.
AAMI TIR45:2023 provides guidance on using Agile practices in medical device software development while remaining compliant with regulatory expectations and relevant standards and FDA guidance. [3] FDA recognizes AAMI TIR45:2023 (FR Recognition No. 13-143) as a complete recognized consensus standard. [1]
From a program leadership standpoint, this matters because it legitimizes a delivery model that many teams already use. It pushes the conversation away from “Agile vs compliance.” The better question is: how do we run Agile inside a controlled system?
What changed from earlier editions (timeline + magnitude)
TIR45’s update history can be summarized like this:
- 2012: original publication
- 2018: reaffirmed / left as-is
- Early 2020: committee reconvened to update based on community feedback
- 2023: updated edition published
The update was described as not a major rewrite. It was described as significant additions plus minor editorial changes.
Also notable: FDA recognition of AAMI TIR45:2012 (Rec# 13-36) is superseded by recognition of AAMI TIR45:2023; FDA will accept declarations of conformity to the 2012 version until July 2, 2028. [1]
Section-level changes (what to take away operationally)
Sections 1–2: Mostly editorial, keep your foundation tight
Only minor editorial changes were highlighted. My takeaway: if your Quality System alignment is weak (definitions, lifecycle model, governance), Agile will amplify chaos. These sections remind teams that fundamentals still matter. [8]
Section 3: Definitions updated for new topics
Two new definitions were added. In practice, definitions are often the “small text” that causes big audit friction. This happens when teams use Agile vocabulary, but auditors evaluate evidence through QMS language. Align terms early. [8]
Section 4: Foundation restructured; appendices carry more context
Some deeper Agile-Manifesto context moved into appendix. Most content remains. [8] My takeaway: keep the narrative of “Agile values” separate from “regulated controls.” Then map the two on purpose.
Section 5: Foundational concepts (new topics that address real-world pain)
The discussion highlighted four “new topic” areas.
5.1 Aligning Agile and non-Agile teams
This is the real world: software might sprint, while hardware, systems engineering, RA/QA, manufacturing, suppliers, and clinical planning often operate on phase-gated cadences.
How I implement this:
- Define interface milestones both cadences can commit to (architecture baselines, integration builds, verification readiness points).
- Use a “translation layer” between plans (sprint goals/increments ↔ phase deliverables/reviews).
- Make dependencies and evidence expectations explicit during backlog refinement (what evidence must exist by when, and where it will live).
5.2 Approvals and evidence (signatures are not the point)
A key discussion point: approvals are frequently overburdened by signatures. The update clarifies that not every approval requires a signature; only certain approval types do.
How I implement this (QMS first):
- Define what is a formal approval vs an acknowledgement in procedures.
- Allow alternative objective evidence where appropriate (workflow state changes in controlled tools, review records with version control, controlled meeting minutes + decision record).
- Ensure evidence ties to a controlled artifact version (configuration management is non-negotiable).
5.3 The role of software tools in regulated Agile
TIR45 emphasizes Agile should operate within a QMS, not bypass it. [2] This aligns with broader FDA expectations that software evidence supports safe and effective device software functions in premarket review. [4]
How I implement this:
- Document intended use of each tool (ALM, CI, test mgmt, e-sign workflows). [5][6]
- Verify audit trail, access control, data integrity, record retention. [5][6]
- Apply a validation/assurance approach proportional to risk (tool failure impact). [5][6]
5.4 Objective evidence for IEC 62304 activities (continuous, not “big bang”)
Focus on continuous assessment of quality through continuous testing/CI and continuous “getting to done” as per your definitions of done. [2]
How I implement this (evidence-by-design):
- Define “objective evidence” per lifecycle activity (requirements, architecture/design, implementation, verification, integration/system testing). [6]
- Make evidence incremental (per story/increment) and retrievable for retention windows. [6]
- Keep traceability alive: requirements ↔ risk controls ↔ tests ↔ results. [4][6]
The Section 6 expansion: practices-first compliance guidance
Older content leaned heavily on mapping Agile to the IEC 62304 structure. The update adds guidance from the opposite direction. It starts with Agile practices. It then describes how those practices can support compliance expectations. [8]
6.2 Using Agile practices for regulatory compliance (practices to controls)
Here’s the practical “mapping” I use:
- Product backlog / refinement / Definition of Ready
- Treat as a living system for design inputs and their evolution.
- Definition of Ready can encode compliance readiness: acceptance criteria, risk notes, trace targets, review approach.
- Sprint backlog
- Your execution plan that makes visible the work needed for compliance: implementation, verification, documentation updates, reviews.
- Definition of Done
- “Done” must include the evidence your QMS requires (reviews, tests, trace updates, risk updates), otherwise you’re just deferring compliance debt.
- This matches the Scrum Guide framing: the Definition of Done is a formal description of the Increment when it meets the quality measures required for the product. [7]
- Sprint Review
- A recurring, structured checkpoint for incremental outcomes and evidence. Depending on your QMS, it can support or feed formal design review activities.
- Roles (Product Owner / Scrum Master / Development Team)
- As per expert discussions I’ve heard, Scrum terms are used, but the concepts generalize to other Agile frameworks, they are not intended to be reduced to Scrum as one may think from a first read.
- A key callout was the Scrum Master/coach role helping the team make the “it depends” decisions about how to satisfy the quality system while iterating.
- Continuous Integration / TDD / coding standards
- These can strengthen objective evidence generation through repeatable automated verification signals and consistent implementation quality.
- Document how outputs are captured, retained, and reviewed as records.
6.3 Addressing regulatory requirements beyond IEC 62304 (systems reality)
The update adds guidance beyond “pure 62304.” Real products extend into validation, safety risk management, cybersecurity, and usability.
The pattern emphasized is one I strongly agree with:
- define an overall strategy at product level
- execute incrementally at release/increment/story levels
- keep specific “final / production-equivalent” obligations where required. Do not wait until the end to do meaningful work.
How I expand each area in execution:
- Design validation
- Plan what must happen on production-equivalent units vs what can be learned earlier with prototypes/simulations.
- Use formative activities early; reserve required summative/clinical/human factors validations for the appropriate stage.
- Safety risk management (ISO 14971 alignment)
- Keep risk management alive per story/increment: does this change introduce hazards, modify severity/probability, or change risk controls?
- Aggregate release-level evidence and maintain trace links from risk control ↔ implementation ↔ verification evidence.
- Cybersecurity
- Treat security as continuous: integrate threats and security requirements into backlog; verify incrementally; retain evidence (e.g., dependency scanning results, SAST outputs, have your SBOM done early and keep it up-to-date).
- Usability / human factors
- Run usability learning incrementally (formative evaluations) and feed results back into backlog refinement.
- Plan summative validation at the correct stage, but don’t defer usability thinking until the end.
Why this matters to leaders (the “incremental compliance” operating model)
From my experience leading remediation programs and audit readiness efforts, “Agile in regulated environments” succeeds when teams operationalize three principles:
- Controls are not a phase: controls are embedded in how work is refined, executed, reviewed, and released.
- Evidence is produced continuously: evidence is a byproduct of normal work, not a special event.
- Definitions close ambiguity: Definition of Ready, Definition of Done, role expectations, and record expectations are explicit and trained, get away from “tribal knowledge.”
TIR45:2023’s changes reinforce these principles. Sections 5 and 6 are the clearest examples. The guidance is closer to what real organizations need.
I’m Leo Jiménez. I lead engineering teams and programs. I have 15+ years delivering cross-functional work in regulated environments, including medical devices and safety-critical aerospace. I build repeatable delivery governance. I strengthen requirements-to-test traceability. I focus on audit-ready evidence under Quality System expectations.
References
[1] FDA Recognized Consensus Standards entry for AAMI TIR45:2023 (FR Recognition No. 13-143; transition period and scope/abstract). https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=46295
[2] Greenlight Guru — “AAMI TIR45: Closing the Gap Between Agile Software Development & Medical Device Regulations” (public summary and interpretation). https://www.greenlight.guru/blog/aami-tir45
[3] AAMI (ARRAY) landing page and abstract for AAMI TIR45:2023; Guidance on the use of agile practices in the development of medical device software. https://array.aami.org/doi/10.2345/9781570208683
[4] FDA guidance: Content of Premarket Submissions for Device Software Functions (June 2023). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
[5] FDA guidance: Off-The-Shelf Software Use in Medical Devices (Aug 2023). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices
[6] FDA guidance: General Principles of Software Validation (Jan 2002). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation
[7] The Scrum Guide (2020): Increment commitment and Definition of Done. https://scrumguides.org/scrum-guide.html
[8] Johner Institute summary article: TIR 45: Agile software development for medical devices (includes a public summary and notes on the 2023 update). https://blog.johner-institute.com/iec-62304-medical-software/tir-45-agile-software-development/
[9] PEDCO overview: AGILE practices in the development of medical device software (public overview referencing TIR45). https://www.pedco.eu/tir45-agile-in-medical/
Leave a Reply