Agile Software Development In Bio/Pharma & Medical Devices, Part 3

By Allan Marinelli and Howard Mann

The pharmaceutical industry, under the FDA and other regulatory bodies, has been utilizing computer software/systems validation testing methodologies to validate software under GxP environments in alignment with the principles of good automated manufacturing practices (GAMP) since the first published guidance in 1994.^1,2

Read part 1 of this article series here and part 2 here, if you’ve missed them and want to get caught up. In part 3 of this three-part series, we will further dive into the use of Agile methodology, including a discussion of practices toward alignment with the pharmaceutical, biopharmaceutical, vaccine, medical device, and cell/gene therapy industries, with a focus on the following topics:

• Rationale for the software system testing phase
• Software release
• Configuration management and change management
• Corrective and preventive action

Aligning On Practices^3,4

Attempting to align Agile practices with regulatory goals, concepts, and practices entails accounting for the following elements prior to introducing any Agile approaches into your medical device quality management system (QMS). This can also be applied within the pharmaceutical, biopharmaceutical, cell & gene therapy, and vaccine industries.

Rationale For Software System Testing Phase

Let’s examine the testing phase of the Agile model and how that testing should be documented.

1. Importance of Testing

Unlike a Waterfall or linear approach that involves much documentation while losing focus on developing the most efficient software features in the shortest time to market, Agile testing involves the continual development of software by treating many software versions as placeholders that can be used later as temporary food for thought. Subsequently, excerpts or partial copies of the tangible functional software parameters/attributes/programming codes are inserted into the next updated version. Some of the ideas from older versions can also be brought into the development of the most up-to-date software version (release layer).

In other words, some of the added-value ideas are perpetually being used in the development of the most current software version, so the development of the software is continuously fine-tuned toward alignment with:

1. Story layer:  The software system testing is focused on verifying the functionality covered by the story with tests that are in alignment with the requirements related to the defined story.
2. Increment layer: Multiple stories come together to provide a set of related functionalities as defined in the requirements.
3. Release layers: This entails focusing on regression testing and not likely factoring in requirements at this stage.

2. The Value of Continuous Testing: An Advantage Of The Agile Model

There is continuous loop/sub-loop feedback endorsed by the involved stakeholders in which the code can easily be altered at the early stages of development in order to ensure proper functionality of the software, as opposed to making code alterations at a later stage of software development as in the linear models (such as Waterfall). The latter approach can result in the development being more difficult, increasing the cost of operational development of the software while potentially creating additional unnecessary risky conditions.

3. Importance of Regression Testing (Most Likely Performed In The Release Layer)

In the Agile methodology, the codes/attributes developed within the story and increment layers may not be fully accounted for to ensure correctness in the final version of the software as a result of simultaneous various workable software versions.  In a linear methodology, such as Waterfall, a single workable software version is performed. Therefore, regression testing will be performed in the Agile approach to capture and prevent potential anomalies in the code prior to finalizing the software.

4. Creating Tests For Functionality With The Requirements Is Just As Important As Creating Code

When using the Agile methodology, many factors work simultaneously to generate detailed requirements, tests (referred to as acceptance test-driven development), and code.  Some propose that tests should be created prior to developing the code to establish early generation of detailed definition and design the software solution with a focus on its viable functionalities.

Regardless of the order of generating the three aforementioned tasks, in order to satisfactorily complete the story, the creation of tests (the output will measure its intended uses) will in turn demonstrate the generated code is in alignment with the requirements.

The selection of the tests, including the corresponding execution activities, is done by the team during planning as an activity within the story.

The best situation upon generating the code is to create tests as soon as possible; in some cases, one can execute the test at the point where another part of the software was created as a placeholder for future story generation.

5. The Importance Of Documenting Software Testing Results

The importance of documenting software testing results has been continuously evolving, but, ideally, the minimum documentation generated by satisfying regulatory and standard requirements will ensure there is sufficient alignment and robustness with the story, resulting in an efficient software that encompasses quality.

6. Traceability

Not only is traceability a necessity for bridging the requirements of the computerized life cycle through GAMP 5 and Agile methodology approaches, but it can encompass three phases:

1.  Prior To Execution Phase:
   1. The user requirements specification (URS) is a document that is written up front as the first step, while subsequently generating a functional/design specification document with the focus on ensuring that these written documents can be testable or verified against the requirements to close the loop.
2. During The Execution Phase:
   1. The verification test, often referred to as the test-script/test cases/test scenarios or protocols, is put together in alignment with the traceable requirements.
   2. The link between a test execution and the version of software is included as part of the story layer testing, increment layer testing, or release layer testing.
3. Post-Execution Phase (release boundary):
   1. Traceability reports demonstrate that all requirements link the executed activities into the work done in the story, increment, and release layers and have been satisfactorily met.

Software Release

Agile practices are designed to make the process of software release less prone to functional performance deficiencies by using short release cycles and quickly correcting any discovered anomalies. It also increases efficiency by allowing for a near-shippable software product (a product that is complete in every sense except for the additional QMS processes required for regulatory approval).

After the processes for regulatory approval are completed and the previously discussed functional performance attributes of the software have been satisfactorily addressed, other potential refinements (e.g., further eliminating newly discovered anomalies and bugs and improving software performance) are factored in between the previous “near-shipped software product release” and the “to be shipped software product release” for cGMP application. This results in the release (post-regulatory approval of meeting all of the requirements) of the software product in shorter release cycles and minimizes additional corrections of other potential traceable anomalies up front in the first version of the software. In the Waterfall approach, correcting the additional anomalies is done in the next revision of the software.

This will inevitably result in increased efficiency while incorporating the quality paradigm earlier with fewer potential remediations or residual risks after the fact.

Configuration Management And Change Management

The following are key considerations for managing software configuration and change control.

1. Software Configuration Identification

Even though IEC 62304 does not use terminologies such as “baseline,” it is important to establish a quality gate or baseline reference point to encapsulate the configuration items and versions during the development of the software and post software development/continuous integration as part of the subsequent software versions throughout the life cycle.

With continuous integration, this baselining would occur frequently and would consist of a more complete set of iteration life cycle deliverables. More changes to work products might be expected than in a traditional project.

2. Management Of SOUP On Agile Projects

It is important to properly archive the software of unknown provenance (SOUP) items or software items that make up the software system configuration intended to be developed for the medical device such as documents, open-source elements, compilers, source code libraries, integrated development environments (IDEs), testing tools, operating systems, etc. Because of continuous integration, this archival process would have to be performed frequently in an Agile project or as often as the SOUP components are upgraded and integrated into the software configuration system.

3. Agile’s Impact On Change Control

The Agile change control management system as outlined in IEC 62304 is more efficient compared to the traditional methodologies used in a prescriptive regulated environment, while still capturing the changes within the “backlog” during an iteration, coupled with prioritization of additional new features to the design boundaries of the software.

A drawback in the development of software in a highly regulated environment is that you have to first determine when to put the work products under change control, as opposed to immediately documenting the changes in the backlog bucket and then handling them efficiently using the Agile approach.

Another drawback is that you need to allow sufficient time for the designated stakeholders to consider the potential impact of the changes on the software product, project, work environment, and circumstances, etc.

Third, once change control records are generated in the regulated environment, there will be a focus on demonstrating safety and effectiveness, while factoring in design controls after the fact.

The change management system must be effective in evaluating the impact of changes on the system, and there must be robust regression testing to detect unintended impacts.

Corrective and Preventive Action (CAPA)

CAPA is commonly used in quality management to address significant nonconforming issues and prevent their recurrence.

In the context of Agile software development, CAPA can be integrated into the development process to ensure continuous improvement and quality enhancement. The focus is on iterative development, frequent feedback, and adaptability, and emphasizes identifying and resolving issues quickly and efficiently, rather than waiting until the end of a project to address them. The CAPA process can be applied in Agile software development in the following ways:

1. Issue Identification: Agile teams encourage open communication and collaboration. This enables early identification of issues, such as defects, process inefficiencies, or customer concerns. The Agile team, including developers, testers, and stakeholders, actively participates in identifying problems.
2. Issue Prioritization: Once issues are identified, they are prioritized based on their severity, impact on project goals, and customer requirements. This prioritization helps the team determine the most critical issues to address first.
3. Quick Remediation: Agile teams aim to address issues rapidly. Depending on the severity and complexity, the team may opt for temporary workarounds to mitigate immediate risks while planning for a permanent solution. The emphasis is on quick feedback loops and continuous improvement.
4. Root Cause Analysis: Agile teams conduct root cause analysis to understand the underlying causes of issues. This analysis helps identify systemic problems rather than just treating the symptoms. By addressing root causes, the team can prevent the recurrence of similar issues in the future.
5. Collaborative Problem Solving: Agile teams engage in collaborative problem-solving to find solutions. The focus is on involving team members with diverse perspectives and expertise to brainstorm and implement effective solutions.
6. Preventive Actions: In addition to resolving immediate issues, Agile teams also identify preventive actions to avoid similar problems in the future. These actions can include process improvements, additional quality assurance measures, automation of tests, or training to enhance skills and knowledge.
7. Continuous Improvement: Agile is built on the principle of continuous improvement. The team regularly reflects on its practices, identifies areas for improvement, and implements changes to enhance efficiency, quality, and customer satisfaction.

By integrating CAPA principles into Agile software development, teams can foster a culture of quality, rapid issue resolution, and continuous improvement. This approach helps minimize risks, ensures timely delivery of high-quality software, and enhances customer satisfaction.

Conclusion

It is not only important to understand all the elements and testing needed as part of the software life cycle, but you must also maintain/sustain the quality of the final released product after the fact through adherence to the configuration management/change management and CAPA programs of your company.

References

1. https://www.chemeurope.com/en/encyclopedia/Good_Automated_Manufacturing_Practice.html
2. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software
3. https://www.meddeviceonline.com/doc/pharma-software-methodologies-in-biopharma-medical-devices-0001
4. Guidance On The Use Of Agile Practices In The Development Of Medical Device Software, https://webstore.ansi.org/Standards/AAMI/AAMITIR452012R2018

About The Authors:

Allan Marinelli is the president of Quality Validation 360 and has more than 25 years of experience within the pharmaceutical, medical device (Class 3), vaccine, and food/beverage industries. His cGMP experience has cultivated expertise in quality assurance, compliance, quality systems, quality engineering, remediation and validation roles controlled under FDA, EMA, and international regulations. His experience includes quality systems, CAPA, change control, QA deviation, equipment, process, cleaning, and computer validation, as well as quality assurance management, project management, and strategies using the ASTM-E2500, GAMP 5, and ICH Q9 approaches. Marinelli has contributed to ISPE baseline GAMP and engineering manuals.

Howard Mann works as an independent consultant and/or contractor in the operational, regulatory, and quality assurance arenas. He has extensive experience in the healthcare industry and provides technical leadership guidance to the business development process, including the product development process in all areas of GxP compliance.