In the world of life sciences, an endless stream of compliance documents is thrown around. It’s no different for computerized systems. It’s not always that easy to know what your system needs to be compliant and how you might achieve compliance.
One of the documents we often come across is ‘Medical Device Software – Part 2: Validation of Software for Medical Device Quality Systems, ISO/TR 80002-2:2017 , IDT‘. We will refer to it as ISO 80002.
As required by ISO 13485:2016: 4.1.6, 7.5.6, and 7.6 ., this document applies to software used in medical device quality systems, including:
- Software used in quality management systems.
- Manufacturing
- Service delivery
- Monitoring and measurement of requirements.
It consists of a list of rules with which the system must comply. But what should we do with a list of rules and vague suggestions? It could leave people with more questions than answers.
This is where GAMP5 (Good Automated Manufacturing Practice) has tried to provide a practical guide for the validation and management of automated systems used in pharmacy.
This guide was published by the International Society for Pharmaceutical Engineering (ISPE) and is used as an international reference for regulatory compliance.
Now we may wonder if systems comply with ISO 80002-2 if we follow all the guidelines described in GAMP5. In this article, we address this question, hoping to expand your knowledge on:
- Required processes and deliverables for ISO 80002-2
- Which of these processes are included in GAMP5
We make the comparison so you don’t have to.
Enjoy the read!
How will we compare ISO 80002-2 and GAMP5?
We will go through the lifecycle of computerized systems for non-product software and computerized systems used in pharma. ISO 80002 states that many development life-cycle models can be applied.
It also states that none of these models will be advocated or recommended. They do, however, expect a controlled methodology, which is explained in the document in quite some detail. What does this mean in practice? Follow the rules in the document!
The product life cycle for both exists of four main phases:
- Concept, where you define what your system should do.
- Project, where you develop and prove that your solution works properly.
- Operation, where you actually use your validated system and try to keep it in a validated state.
- Retirement, where you say goodbye and part ways with your system
Figure 1 – Lifecycle of computerized systems for non-product software and computerized systems used in pharma
During this exercise, we will have a look at each phase and list the deliverables and activities required by ISO 80002, and how/if GAMP5 handles these topics.
Supporting processes
Before we look at each phase individually, there are some required processes that are not specific for any phase of the life cycle but are implemented in one way or another during each phase. GAMP5 lists these under the Supporting Processes. Let us discuss the most important ones:
Risk Management
ISO 80002 states that risk management should be in place and a risk-based approach should be used. It also states that the risks associated with the software should be reduced to an acceptable level.
The GAMP5 guide has incorporated this in chapter 5 and Appendix M3. The appendix explains how to incorporate science-based quality risk management in all the lifecycle phases, and how to scale, mitigate and deal with residual risks:
Figure 2 – How to incorporate science-based quality risk management in all the lifecycle phases, and how to scale, mitigate and deal with residual risks according to GAMP5, Chapter 5 and Appendix 3
Traceability
Ensuring traceability between all activities is not only required by ISO 80002, but also a practical way to keep track of what has been done and why.
What does this mean? Well, by linking business process needs with requirements, and linking those to the verification efforts and risk management, we achieve a mapping.
This mapping, often called traceability matrix and can be used to ensure that all requirements are properly addressed.
You should not look at traceability as just something that should be done. I cannot emphasise enough how practical proper traceability is when performing risk management or making impact assessments.
Life cycle phases
1. Proof of concept
The proof of concept is referred to as the concept phase in GAMP5. In the concept phase, everything starts.
Before a solution can be developed or purchased, you need to know what it is you and your stakeholders need and what the solution will be used for (intended use). To record these needs, User Requirements need to be established. Besides that, it is a good idea to already start looking at potential suppliers. This could help you with getting an idea of what is already out there.
Even though the concept phase is not formally part of the scope of ISO 80002, concepts like use requirements, purpose and intent (intended use), are required by ISO 80002 and are included and well explained in GAMP5.
2. Project Phase
The project phase is where all the actual work gets done to develop the solution, prove that it works properly and implement it.
The project phase includes 5 sub-phases:
- Planning
- Specifications
- Development: configuration and coding
- Verification
- Reporting and release
We will make a standstill at some of the deliverables and required activities in these sub-phases.
Planning
Planning should cover all required activities, responsibilities, procedures, and timelines. Look at it as project management for everything that needs to be done until the solution can be used.
What is required by ISO 80002 is that all validation activities and deliverables are recorded in a Validation Plan. According to GAMP5, this is the responsibility of the process owner and should include:
- The scope of the system
- Objectives of the validation process
- Applicable main regulations
If needed, the User Requirements should be revised as well. Chances are high that some of these need to be finetuned.
Development – Specification, configuration, and coding
This step corresponds to the development phase.
These steps are highly dependent on your specific cases. It is quite logical that off-the-shelf software requires a different approach than software that will be fully developed by yourself.
Before you develop something, you not only need to know what you will be developing and why that is important or needed but also how this will be implemented.
This is the function of specifications or design specifications. This is of course if you will develop a new or highly customized system.
In this phase, the solution is built/adapted/configured/… according to the specifications and/or user requirements.
ISO 80002 does not state how you should develop your software. For as long as it is compliant with their other rules, they are happy.
Verification
Verification is the activity that is in place to confirm that the specifications have been met. This is done by testing.
ISO 80002 leaves testing open for interpretation. It states that testing should be based on the risk drivers and factors and should provide an appropriate level of confidence to demonstrate that the software meets the requirements and design specifications. It also states that testing activities should be planned.
GAMP5 also approaches testing from a risk-based point of view, where all activities should be planned. Appendix D5 describes how testing of GxP-regulated computerized systems could be done.
Additionally, a separate guide is on the market about a risk-based approach to testing of GxP Systems.
Reporting and Release
The Validation Report is the most known deliverable during this phase. This is a summary of activities performed, a listing of any deviation, open corrective actions, and a statement for fitness of use of the system. The GAMP5 guide ticks all the checkboxes needed for ISO 80002 for the validation report.
Planning for maintenance: ISO 80002 states that planning for maintenance during the development phase can define which of the operational activities can be done without affecting validation and which changes require validation efforts.
In essence, you should think about what low-risk regular activities will be performed to maintain the proper functioning of the system. In GAMP5 this is integrated during development into the specification subphase.
Once the deliverables are met, the next phase can start.
Do not forget to celebrate this important milestone with all your stakeholders!
3. Operation Phase – Maintain Phase
The operation phase is where you will actually use the system. With a bit of luck, this phase is the longest of all phases so far.
ISO 80002 deliverables
- Change management
- Periodic monitoring
- Incident management
- Configuration management
During the operation phase, the attempt is to keep the computerized system in a validated state. Chances are, at some point during the operation phase, certain actions will be required to keep the automated system performing well and still in that desired validated state. This is where change management will play an important role, as stated in ISO 13485 section 4.1.4. In case you are interested in change management, please read this blog post. For most systems, the operational phase is the longest phase, so give it enough attention.
Risk-based, documented periodic reviews should be in place to evaluate the impact on patient safety, product quality and data integrity.
In an ideal world, there are no problems. Unfortunately, we don’t live in an ideal world. This is why incident management should be in place.
This is not specifically mentioned in ISO 80002. Instead, it refers to ISO 13485. This is an example of what the issues are while working with ISO documents. Not all information is placed in one document. ISO 13485 describes incidents and events in the same way as GAMP5:
- Incident and problem management
- Corrective and Preventive Action (CAPA) process
In short, incidents are reported effects in the form of events linked to the system, that could originate from anywhere. These events should be categorized and investigated with the goal of achieving a timely resolution. Did you know that the word “incident” is not even in ISO 80002-2?
CAPA is a root-cause based process for investigating, understanding, correcting, and preventing unwanted situations. The prevention is mostly done by changes to the processes. Many Incidents can be part of one CAPA.
Configuration management should be present. It is mentioned as a deliverable during the operation phase. It could be beneficial to already establish this process earlier because it might help to keep track of potential intermediate builds or versions during development or coding itself. Configuration management will be continued until the system retires.
4. Retirement Phase
In this phase, your system life cycle comes to an end. The easiest way is to just stop using it. Also here, it is not that simple. There are some rules in place to ensure that this is properly done.
ISO 80002 does not provide specific deliverables for this phase. Instead, it states that this is dependent on the type of software being retired and its intended use.
The retiring of the system is seen as a change (see: change management), where a system is taken out of use. The impact of that change is that the system is no longer in use to perform certain tasks or fulfil certain functions.
GAMP5 also looks at this as a change, and additionally it adds a layer of how to migrate, archive and retrieve data that was stored and used by the system. A list of issues to consider are provided in ISO 80002. These should be taken into account in during the impact assessment of the change.
Comparison between ISO 80002-2 and GAMP5: conclusion
We have made an attempt to compile the deliverables for ISO 80002-2 and if/how GAMP5 handles these topics. We have found that these two are very similar in the topics they handle. GAMP5 is a complete guide that includes almost all topics for ISO 80002.
Because of this, we can conclude that if your system has been (properly) set up according to the GAMP5 guideline, you are covered for ISO 80002-2. Additionally, there are some topics that are included in GAMP5, that are not required by ISO 80002.
Is using GAMP5 a good way to go for your non-product software?
This is probably the most important question. However, like it goes with most answers, this one also starts with: Well, it depends…
Some people are somewhat reluctant to working with GAMP5. We do understand that an almost 400-page book can be quite overwhelming instead of the 84 pages of ISO 80002-2. After making this comparison, we can conclude that this almost 5-times more pages, does not add workload. On the contrary, a thorough explanation on how to develop and implement certain processes, could reduce time.
Just to be clear, working with only ISO 80002 is not a wrong way of doing things. In our opinion, the GAMP5 guide is just much easier to work with. It eliminates most of the troubles you encounter when working with the ISO-Standards. The required deliverables for ISO 80002-2, are reworked and incorporated in GAMP5 in a more practical way.
So, do you use ISO 80002 or GAMP5? As with most things in life, it is a choice. We prefer the more practical way.
Need help with ISO80002 or GAMP5?
New to systems validation and need help to get started? Our experts will be happy to support you in your procedures for computer systems, depending on your available resources. Please do not hesitate to contact us if you have any questions.
Expert knowledge in Computer Systems Validation
- PIC/S GUIDANCE GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS, PI 011-3 25 September 2007.
- GAMP 5 A risk-based approach to compliant GxP Computerized System, ISPE, 2008.
- https://healthcareitskills.com/information-technology-change-control-process-change-board/
- General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002.
- AudraLex The Rules Governing Medicinal Products in the European Union, Volume 4: Good Manufacturing Practice – Medicinal Products for Human and Veterinary Use – Annex11: Computerised Systems
- ISO 80002-2 Medical device software —Part 2: Validation of software for medical device quality systems
- ISO 13485:2016 Medical devices — Quality management systems —Requirements for regulatory purposes
