In a constantly changing world that is dominated by uncertainty, many industries have already adopted Agile software practices, aiming at enhancing flexibility within their business processes and enabling innovation. Although the medical device sector has already embraced Agile within their systems and business organization, the pharmaceutical industry is lagging behind, mostly due to compliance concerns as well as misconceptions regarding regulatory expectations in a GxP environment.
In this part 1 of a series article, we use the ISPE GAMP Good Practice Guide: Enabling Innovation as a reference to clarify, how to correct Agile implementation can be perfectly aligned with GxP and ISPE GAMP 5 principles and enable flexibility and innovation while maintaining all the development steps of the Waterfall model. It covers the requirements and specifications and the overall Agile topic in regulated environments.
Figure 1: Comparison of the Waterfall and Agile methodologies regarding Software development. Adapted from easyagile.com
Requirement Identification & Design Specifications
In a GxP environment, systems need to be fit-for-intended use. This is enabled by identifying functional and non-functional requirements which are then used to shape system specifications that will drive development. In the traditional linear or “Waterfall” model, requirements are identified in the form of the User Requirement Specification - URS, a document that needs to be produced, reviewed, and approved and any subsequent changes to it are required to undergo through the same review and approval process. This approach may be appropriate when the development is straightforward, and the developers have prior experience with similar products, or if the regulated company has a very clear set of expectations as part of the tender process for supplier selection.
However, in cases where the scope is less clearly defined, especially when it comes to customized developments, where a “discovery mindset” is followed, Agile is a more suitable approach. Its adoption enables faster initial system deployment and subsequent incremental development, and it can be executed in a controlled way that adheres to GxP requirements. This model is supported by the EU Annex 11, which is aligned with the GAMP 5 Guide: Compliant GxP Computerized Systems that states in Appendix D1: “Requirements may not initially be fully defined, e.g., for some Category 5 systems, requirements are developed during subsequent phases of the project”.
In Agile, requirements are identified within user stories, epics, or features, referred to as Product Backlog Items (PBIs), and managed on a backlog basis. Using tools that allow for the addition and change of requirements, the development can be compliant if these tools are qualified, including audit trailing, approvals, status control, filtering, reporting, and traceability. As depicted in Figure 2, scrum uses the product backlog, which is usually stored in an Agile planning tool, thus providing the various digitalization benefits mentioned above. The PBIs should have high-level user acceptance criteria so that the scrum team can understand their scope and use them as a basis for test cases.
Furthermore, the following aspects of acceptance criteria shall be considered
- They should have the same attributes of a traditional waterfall/ linear set of requirements with respect to
- Data migration
- Security requirements
- Techniques such as “INVEST” can be leveraged to check for good attributes of stories.
It’s an acronym for I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, and T – Testable.
- The product backlog needs to be kept up to date, reflecting and anticipating changes, which can be ensured via Backlog Refinement (the team review items on the backlog to ensure the backlog contains the appropriate items).
The most important PBIs at a certain time point, are grouped within the sprint backlog, providing a list of tasks planned for the upcoming sprint to meet the purpose of the sprint. The team discusses during the sprint planning session with the product owner each potential sprint story to understand any architectural, testing, or development tasks, issues, or risks and establishes the sprint goal of having an approved and prioritized sprint backlog.
A regulated company shall identify all GxP-related requirements based on the intended use of the system and ensure that these are included within the Minimum Viable Product (MVP) for the initial release of the system into production use (initial launch). GxP compliance during requirement identification can be facilitated by
- Mapping GxP-related requirements against the Agile artifacts of the already developed software
- Using qualified tools that allow risk-based testing focusing specifically on these areas and ensuring traceability to testing/verification activities
- Breaking the system into its functions/ features and assigning a risk score to these features could be applied at the epic level
- Considering hierarchical relationships when applying critical thinking to avoid the potential cascade of higher-risk scores to lower-level items that are lower risk
- Developing standard libraries of appropriate PBIs for nonfunctional requirements that can be reused for subsequent software development
Figure 2: Scrum Framework Model, adapted from ISPE GAMP Good Practice Guide: Enabling Innovation, source scrum.org
This is the first of a two-part article about the Agile methodology in regulated environments series. The second part depicts the tests and approval approaches adopted in Agile applications on GxP scenarios.
Stay tuned and subscribe to our page to be the first one to receive the next part of this article, and if you have any questions, contact us at firstname.lastname@example.org.