Documenting Software for FDA Submissions

When medical device companies consider Agile development methods, they often run into the key criticism that Agile groups produce little to no documentation, and that Agile stands in contradiction to the lifecycle standards outlined in IEC 62304. In fact, those principles - have clear processes for quality management system, risk management process, software maintenance, configuration management, and problem resolution - actually augment rather than contradict the Agile manifesto.

The Agile approach helps companies avoid hearing bad news late in a project, by delivering incrementally, integrating regularly, and leaving room for learning as the user stories are refined. In addition, it provides real information on progress and project speed to stakeholders outside the development group.

Documentation under Agile, then, can take advantage of iterative development. Each objection to Agile reveals another point of discipline for effective Agile teams. Requirements can be captured as they are elaborated, and test cases can be firmed up as they are generated during development. For these pieces to fit together, quality processes need to be flexible.

Even clearer is the case for hazard analysis - it and Agile are made for each other. Just as requirements are refined in the course of a project, so too does the knowledge of hazards and design of their mitigations. Risk management, therefore, can and should be included in iteration tasks.

We are coming to see that Agile methods not only result in acceptable medical device development, but lead to much better outcomes. IEC 62304 does not specify any lifecycle model (and states as much); documentation can therefore grow out of iterative activities.

Why you should attend :

Agile methods are appearing more and more in regulated health-related applications. The teams carrying out this development must work both rapidly and flexibly, since they are obligated to satisfy not only their business management, but also the patients and caregivers, and, of course, the regulatory bodies who must approve their products. Teams must document all aspects of their development - requirements, design, tests, hazard analysis, usability, and traceability. How do we achieve all that and remain Agile?

Many companies struggle with meeting all these expectations; software-related product recalls and failed companies are the legacy of traditional, sequential methods.

How can we gather these as development proceeds, while minimizing overhead? How can we assure that inputs are reviewed and approved, without getting mired in the document signoff spiral? How can we address design reviews without bogging down the team in long, droning meetings? How can we capture traceability as a natural outcome of our work?

Experience is showing, and the AAMI Agile report (TIR 45) has stated, that when Agile is properly applied in the context of a quality system and robust safety risk management, its emphasis on nimbleness and ongoing learning can be reconciled with regulatory expectations of well-documented development.

Areas Covered in the Session:

• Agile vs IEC 62304: an apparent contradiction?
• The role and value of documentation
• The REAL regulatory requirements
• Specific documents required for an FDA submission
• Areas where most development processes bog down
• Iteration - well suited for risk, usability, and design reviews
• Key practices to bridge the Agile and regulated worlds
• Agile is not only acceptable for medical device software, but can be clearly superior

Who Will Benefit:

• Regulatory Specialists
• Quality Assurance Specialists
• Documentation Specialists
• Test Managers
• Software Team Leaders and Lead Developers
• Project and Program Managers