WHITE PAPER

EMBRACING AGILE PRACTICES

IN MEDICAL DEVICE SOFTWARE
DEVELOPMENT
 Agile as a development methodology has been there for over two decades. It has been prevalent in non-regulated industries such as
e-commerce, retail etc., but the medical device industry has been cautious in embracing this methodology. This article explores the ways
of implementing an agile methodology for developing medical device software through a defined framework. This framework provides
guidance on agile implementation, coupled with information on abiding by stipulated regulations which are critical to meet the objectives of
regulatory compliance and patient safety.

Benefits of Agile reliable, the agile methodology does not have • Functioning software vs elaborate
sufficient rigor to be used in these critical documentation
In today’s highly competitive world, systems to ensure regulatory compliance.
organizations whose products make it to the Development teams need to
market early have a high chance to capture In case of a medical device with embedded produce documentation which
the market share. Agile ways of working pave software, medical device developers have can be valuable for themselves
the way to get to market swiftly and thereby a perception that it may not be feasible to and for regulatory personnel. The
provide the device manufacturer with early use agile methods to develop the software documentation is continuously
mover advantages. component, as the hardware component evolving rather than being a one-
cannot be turned around as quickly as the time update. Continuous integration,
Agile emphasizes frequent development
software. deployment, and testing practices
and testing cycles. This enables early defect
are the key to a good quality working
detection and fixing of issues, thereby leading
software.
to improved product quality. AAMI TIR45
• Rigorous change control system vs
End users get to see interim versions of the All the above factors reflect lack of proper
planning
product at regular intervals and can provide interpretation of agile. In fact, none of the
instant feedback and thereby be confident of regulations or standards, mandate any Apart from good planning practices,
product usability. methodology to develop the medical device establishing a robust change
New product development exposes new risk software. To address these industry concerns, management system is a crucial
areas which are addressed better by following a committee of industry leaders came up factor in effectively managing the
agile methods. As risks are identified at a with AAMI-TIR45 in the year 2012 which acts ability to change quickly to align with
feature level, implementation of risk mitigation as a guide for software-based medical device the requirement.
actions and continuous feedback on the same development.
• Collaboration with Client vs
by end-users help in making the feature and
Contractual agreement
eventually the overall product more robust.
AAMI TIR45 and Agile Manifesto Collaboration with client (especially
Product quality is one of the key tenets product owner) on a regular basis
Adoption Challenges
of regulation in the LS Industry. Agile is critical to the success of agile
Despite the benefits, there are some methodology also emphasizes building projects. Continuous focus on
challenges in adopting agile by many medical quality into the product. Thus, the vision achieving “DONE” criteria is the key.
device companies. of regulation and agile converge at this
point of building high-quality software. The
There is a natural resistance among medical
interpretation of values of Agile Manifesto
AAMI TIR45 and IEC 62304
device software developers to switch from
from AAMI TIR45 perspective is as below. Alignment
the de facto waterfall methodology to agile.
This can also be due to the inherent culture • Individuals vs processes and tools IEC 62304 is an international standard
within the organization wherein the senior on medical device software lifecycle
management itself is not willing to try and The existence of processes and tools processes, and it is accepted by most
adapt to new methodologies. Changing cannot ensure success by themselves. global regulatory bodies including the
the way an organization operates is always The constant emphasis on safety and risk FDA.
difficult. aspects through backlog prioritization,
retrospections, and planning practices The below snapshot (Fig 1) depicts
There is a belief in the industry that, since help in achieving this value of the Agile the alignment of AAMI TIR45 with IEC
medical devices need to be safe, effective, and Manifesto. 62304(Till Design Verification).

External Document © 2022 Infosys Limited

 IEC62304
1.Software development planning

2.Software requirement 3.S/w architecture and 4.S/w detailed design 5.Dev+Unit test 6.S/w build+integ test 7.System testing 8.Release
analysis design

PRODUCT 1.Software 2.Requirement

development analysis-High 3.Software Product Configuration Change
Risk management Requirements
LAYER plan-Product roll
out plan
level Product
backlog
architecture and
design
management management traceability

RELEASE 1.Software 6.Software 7.Software

LAYER development integration system
+Regression
8.Release
plan +
Integ testing(QA) Release 1 Release 2 testing(QA)

SPRINT 6.Software
AAMI TIR 45

1.Software integration 7.Software

LAYER development system
+
SP1 SP2 SP3 SP4 plan +Regression
Integ testing(QA)
testing(QA)

STORY
LAYER
US US US
US1 US2 US3 US4 US5 US6 US7 US8 US9
10 11 12

2.Req analysis:- User story elaboration, Acceptance criteria

3. S/w architecture & design (Emerging) 4.Unit design specification(Detailed design)

5.Development and unit testing 6.S/w Integ testing

US User story SP Sprint

Fig 1. AAMI TIR45 aligned with IEC62304(Till Design Verification)

As per AAMI-TIR45 the design controls are deliverables such as risk register, requirement The phase which confirms the completion
organized across multiple layers as below traceability, etc. are continuous in nature and of all the defined design & development
are executed across the product life cycle. activities is known as Definition of Done (DOD)
• Story layer is for the development of phase. Continuous integration, continuous
identified requirements Each sprint has multiple user stories to be
review, and testing practices ensure the
developed. Various activities have to be
• Sprint layer is a culmination of multiple required output quality prior to the start of SIT.
accomplished to consider the user stories
user stories as “Ready” to move into the development The entire sprint would be assessed for
phase. The phase that deals with the ensuring the proper functioning of the
• Release layer consists of multiple sprints
completion of prerequisite activities for software in line with the requirements, which
• Product/Project layer consists of multiple the user story development is known as is done in the System Integration Test (SIT)
releases Definition of Ready (DOR) phase.
phase. Formal milestone reviews are planned
Processes such as configuration management, Once the user stories are ready, they are at sprint and release levels, thus satisfying the
change management, risk management etc., followed by design & development activities. regulatory requirements.
Test cycle#1

• Design verification plan

2weeks Prior
sprint start

• identified stories per sprint • UDS update(High level)+Visual design • Dry run of all test case for
DOR

• Acceptance criteria for story • Finalize architecture (if required) release

• Risk identification • In sprint testing scenarios • Defect detection

• Ongoing UDS updates • Static code analysis • Defect fixing

Test cycle#2

• Source code development • Unit testing • Test script corrections

Week1 To

DOD
Week 4

• Source code review(Manual) • Code coverage measurement • Rerun of failed test scripts
• Develop test cases • In sprint testing(Dry runs) in Dev • Final approval of test scripts
• Sprint retrospection environment

• Formal design verification

Release cycle

• Defects triaged
• Test plan preparation
onwards

of product
Week5

• Update traceability
• Test cases approval • Final design verification
SIT

• Test results approval

• Execute SIT in QA Env summary report
• Test report preparation
*Note: SIT phase can be combined for every 2-3 sprints to optimize effort

Fig2 Proposed agile framework

External Document © 2022 Infosys Limited

Agile Approach for Embedded Software in Medical Device
So far, the framework for leveraging agile methodology for developing a software-only medical device product was discussed. In the following
section, a hybrid agile workflow for developing embedded software (e.g., Software-in-a-Medical Device) is presented. The non-software
components (mechanical and electrical) are developed following the standard waterfall methodology, while the software component is
developed using the agile methodology. At a logical point, all the components are integrated and tested to get feedback on the overall
product functionality. Verification/Validation of the entire unit is done together to ensure the implementation of all requirements into the
product.

Non-Software components follow Waterfall DR1/

DR2 DR3 DR4 DR5

Design Planning Design input Design Output Design Design Design Transfer
Verification Validation

• Overall • Hardware • Hardware & • Mechanical • Clinical • Regulatory

Product requirements mechanical testing evaluation submission
development specification components • Electrical • Address issues and approvals
plan(Including • Electrical construction connectivity from the end • Post market
software) connection • Interlinking testing users Clinical follow
• Product Risk requirements with electrical • HFE testing • Regulatory up
management specification connections • Integration docs • Post market
plan • Material • Baselined testing with preparation surveillance
• Technical requirements configuration Software
feasibility specification • Component • Defect
analysis testing fix/retest

Software component follows Agile Integrate with

Design Output Design Hardware/Electrical
Design input Verification components at
(Sprinted) (Sprinted) regular intervals
• Software
• Software • Refined
verification
requirements( architecture(a
plan
user stories) s needed) Defect fix for
• Software
• Wireframes/vi • Detailed Software integration
system testing
sual designs design issues
• Regression
• High level • Source code
testing
architecture development
• Defect
• Software • Code review
fix/retest
hazard • Unit testing
analysis • Build

Configuration/Change management, Risk management, Requirement traceability, DHF activities

Fig 3. Hybrid agile framework for Software-in-a-Medical Device (embedded software)

Final thoughts
Agile methodology is a key differentiator when it comes to the speed of delivery and improved product quality. Through this article,
the framework to use an agile methodology to develop software for a medical device is presented, which should enable faster product
development and also meet all the necessary regulatory compliance requirements. It is in the best interest of the medical device industry to
adapt agile methodology in software development to reap its benefits and serve the needs of the patient community faster.

About the Author References

Kumar Nagesh 1. Agile software development from https://www.
Senior consultant-Infosys consulting johner-institute.com

2. Introduction to AAM TIR45 from https://Intland.com

For more information, contact askus@infosys.com

© 2022 Infosys Limited, Bengaluru, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys
acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this
documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the
prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.

Infosys.com | NYSE: INFY Stay Connected