Association for the Advancement of Medical Instrumentation, AAMI TIR45:2012 Guidance on the use of AGILE practices in the development of medical device software, 20 August 2012 International Electrotechnical Commission, IEC Medical device software —Software life cycle processes, May, 2006.
ISO 62304: Defines processes that are required in any given SDLC to ensure that 000bit compiles with the creation or maintenance medical device softwareAndy Stopford has over 16 years experience leading teams to deliver pioneering software solutions that enable business goals to be achieved. With experience drawn from the e-commerce, financial, insurance, banking and healthcare sectors he is committed to creating quality software that adheres to best practices and delivers solutions that are robust and help clients achieve business goals.Andy is a software engineer by trade and is a published book author and keen writer with 200 magazine and journal articles over his career. He has a great depth and breadth of knowledge in a variety of technologies and is passionate about all things software engineering.Andy leads the HAVAS HEALTH SOFTWARE team of software engineers to develop solutions that focus on the best possible outcome for the end user that ensure the business needs are met.@andystopford.
This article describes how agile development practices can be adopted inthe highly regulated medical device field. This approach can be easilyadopted by organizations working in other regulated fields.Although medical device regulations do not enforce a fixed lifecycle model,activities are presented in a sequential manner, thus hinting at awaterfall process. Meanwhile, for a decade or more, software teams havebenefitted from agile development methods. Several medical devicemanufacturers have adopted agile practices while keeping development incompliance with regulations, but conflicts arise and decisions have to betaken in favor of agility or formality.
The Association for theAdvancement of Medical Instrumentation (AAMI) has produced a new TechnicalInformation Report, TIR45, that gives guidance on the use of agilepractices in medical device development (see the section for a link). There are two main advantages of the waterfall approach:. It works well in a contractual environment, because the contract canbe let against a well-defined set of requirements. It avoids the problems of developers working without sufficientcontext to know whether they are creating something that is notmaintainable or will prevent other needed functions beingimplemented.However, in practice, it is rare if not impossible to be able to definerequirements completely before starting development work, and if that isdone, they are often obsolete before the project is completed.
Typically,in waterfall approaches, companies actually iterate in each area, and thenext area starts before the first is finished so development can provethat the requirements can actually be met. This means that you areactually doing some agile style development without the rigors of an agileprocess. AgiledevelopmentAgile development is a radically different approach. It recognizes thatrequirements will change as more is learned about the way that theproposed system will be used. It places the emphasis on working systems(typically software), rather than enforcing a process with strictdeliverables.If this approach is not carefully managed, it could degenerate into aprocess with all of the problems that the waterfall was designed to avoid,so various means are used to avoid this. In fact, agile approaches oftenrequire more discipline than waterfall methods.The main control mechanism used in agile processes is to break thedevelopment up into a number of sprints. Each sprint aims eitherto deliver a well-defined subset of the overall required functionality orto perform well-defined restructuring of the architecture of the system.This is known as refactoring in agile terminology.The approach described in the rest of this article is how DiagnosticGrifols has successfully applied agile development methods.
In addition,they integrated the project management method that is often combined with agiledevelopment practices ( scrum is derived from 'scrimmage,' thefull-team huddles in rugby). Figure 2 shows an outline of thisapproach. Outline of the scrum projectmanagement lifecycle. TheV-model processWe should also mention the V-model here, as it is often seen as being justanother way of looking at a waterfall approach. The main distinction fromthe waterfall method is that each of the activities at each level ofdevelopment (the left side of the V) is related to the relevant activityfor verifying and validating the system (the right side of the V).Although viewing it as an extension of the waterfall was the originalintent, most modern interpretations treat the V-model as representingrelationships between activities rather than a set of stages.
In manyways, it does not matter whether we consider the items as activities thatproduce assets or as the assets themselves. V-model process. If we regard the V-model as representing relationships, it is clear that itis equally applicable to waterfall and agile development.
![Aami tir34 2014 pdf Aami tir34 2014 pdf](https://u8c5p3v7.stackpathcdn.com/2.0/wp-content/uploads/2016/03/AMMI-TIR45.jpg)
The onlydifference is that in agile development, you do not have to complete oneactivity (with its related assets) before starting another. In fact, youdo not even have to create any content in the assets, because they becomecontainers that are populated during development. Being agile in a regulated environmentGiven the success of agile development, an inevitable question forcompanies in medical and other regulated industries is: Can we adopt agileapproaches in our environment?
In this section, we describe how onecompany, Diagnostic Grifols, has done this. Where agile and regulatory principles reinforce each other evenwhen they seem to collideAs we stated earlier, regulations currently follow mainly a descriptiveapproach. This means that regulators expect manufacturers to establishtheir own development processes and document them, while showing thattheir processes are robust enough to render safe and effective productswhen followed. Guidance documents and standards define a set of activitiesthat are expected to be found in these processes, while leavingmanufacturers ample room for deciding how to organize these activities intime.This principle of quality assurance by establishment of robust processesseems to collide with the statement that 'we have come to value individuals andinteractions over processes and tools.'
In fact, following the of gathering skilled peopleand providing them with the means to work well just makes a robust processeven more robust. This is because it ensures that teams continuously askthemselves how these are working and whether there are any improvementsneeded. That's something that regulators explicitly ask manufacturers todo.Regulatory inspections seek to assess whether established processes werefollowed or not in the development of the inspected product. From aregulatory standpoint, only objective evidence is valid to support thefact that the process was followed. That leads to certain kinds ofdocumentation that seems to collide with the agile value of 'workingsoftware over comprehensive documentation.'
In fact, both agile andregulated principles serve the same purpose if we equate working softwarewith safe and effective software. Documentation is not an end in itself.It is merely a means of showing that the product is going to fulfill itsintended use in a safe manner, because it has been developed by followinga robust process. Agile principles can help to challenge the documentationthat is produced during development to ensure that only valuable materialsare produced and wasteful ones are eliminated.One of the main activities that guidance documents and standards ask for isto define design inputs. These definitions will be the basis forsubsequent activities, such as architecture, design, coding, and testing.Regulations also expect a final validation activity that shows that theproduct is adequate to fulfill its intended use, as defined in thosedesign inputs. Again, this seems to collide with the agile value of'customer collaboration over contract negotiation,' although it's actuallythe opposite. That's because continuous customer involvement during all ofthe development helps developers fully understand the intended use anduser needs.
It also means that those needs are translated into a set ofdesign inputs that define the system so that other activities can createthe software to fulfill those needs.Finally, development planning is another of the cornerstone activities thatguidance documents and standards ask for to show how the processes thatmanufacturers establish are tailored to a given product and followed.Although this seems to collide with agile value of 'responding to changeover following a plan,' the fact is that agile puts tremendous emphasis onplanning at various levels. Also, regulators admit the need to updateplans as development evolves. Mapping regulated activities in an agile developmentprocessThe diagram in Figure 4 shows how the following regulated activities mapinto an agile development process:. Planning. Requirements analysis (software requirements specification, orSRS).
Architectural design. Detailed design. Coding. Unit, integration, system, and regression testing.
Software releaseFigure 4. Mapping regulatedactivities to an agile development process. These activities are mapped into an agile cycle, more specifically a scrumprocess with its time-boxed sequence of sprints.
A first iterationestablishes the scope of the project, defines a broad plan of the initialreleases, and lays the architectural foundations. After that, a sequenceof releases that extend throughout the life of the product follows. Everyrelease is planned for at the beginning and consists of a succession ofsprints. Before release of the software to the field, a 'hardening' sprintis devoted to ensuring that the software meets all regulatoryrequirements. Optionally, when a release includes a significant number ofsprints, hardening sprints are inserted at certain points duringdevelopment as synchronization points for regulated artifacts.
Thisprevents accumulating either technical or regulatory debts.The following diagram shows the scrum lifecycle in the context of theentire life of a product. Scrum lifecycle in the contextof the product lifecycle.