A Risk-Based approach for Software Category 5
In previous articles, I wrote about A Risk-Based approach for Category 1, Category 3, and Category 4. If you missed these articles, you are welcome to check them out to gain more knowledge about this categorization and approach for each category. This article will cover the Custom packages, which are known in #GAMP? 5 as Category 5.
Category 5 Definition:
This category is defined as a "Custom" ( #Bespoke ) application or software. To make it easier to understand, its software, which is written entirely to meet the expectation of the client/company or small group of users. Examples of these can be found everywhere, not only in automation, or Control Systems. The best-known and which you are using every day is MS #excel. Did you know this? I bet you even didn't think about it. I.e., when you are using the database scripts, macros, and other codes for external interfaces in spreadsheets.
Category 5 Typical Issues:
The confusion, which can be during the assessment of the system, can be divided into multiple stages. Once you know, that your device will be produced by a company, which have some #experience in building similar systems is to categorize the system. It will be Category 3 / 4 / 5? As you read in previous articles, the rigor of the validation is based mostly on the #GAMP categories.
If you will take it as Category 3 you will be limited with the approach in the future, where the future upgrades cant be done by your local staff, till you will validate it as Category 5 ( Validation of Entire System ).
If you will take it as Category 4 you will be limited with the approach in the future, but like in Category 3. In Category 4 you can make some adjustments on a local level but without editing the existing code. Adding / Deleting / Modifying the #recipes can be done, but adding the i.e. #Vision Systems will be impossible without the rigor validation approach in the future. Again, only till you will validate it as Category 5 ( Validation of Entire System ).
Most companies are trying to avoid correctly categorizing the system. How? They are trying to identify the custom / bespoke system as Category 4, or even Category 3. How it′s even possible? They are arguing with the selected common phrase:
The System is already created, we are buying the existing system from the supplier
The first phase is possible to use when the bought machine is the second machine from their production. Then this approach is quietly acceptable because the supplier had "build" this system in the past.
A Risk-Based approach for Category 5?
1. Verify Correct Installation,
Performing the tests against the User Requirements, or Supplier′s specification, where the current software version is evidenced. After the completion of the validation, this version is concerned as validated. The regulatory, such as?#FDA, or?#BSI?are looking for this information on each audit, they are conducting. They are asking about the application?#version?and evidence, that this version was validated.
2. URS Based testing
The most known mistake is, that the systems (No matter what category), are not tested against the User Requirement Specification. The User Requirement Specification is the most guidable document, which should be detailed as possible. Do not forget, that the #URS is the first document, which is read by #CSV.
3. Risk-Assessment based testing
The Risk-Assessment will help you to focus more on the important things, rather than on the simple and non-critical things on the machine. The risk assessment should reflect the outcome of the supplier assessment, GxP risk, size, and complexity of the device. The risk assessment should be focused on the?#patient?#safety?and?#product?#quality.
4. Testing, that demonstrates the fitness for the intended use of the device,
I will continue with the previous example, where in category 4 I wrote about the device, which is measuring the tube length, inspects the tube gloss, and inspects its #diameter. The last added device was a #barcode reader, which was programmed without changing the core code.
领英推荐
But,
The?#management?is required to add a device - Vision System, This Vision System will check the tube for deviations in color, or search for dirt in/on the tube during production ( i.e., Oil Marks, Cuts, Discolorings)
Besides the tests which were performed in the previous case, new tests should be performed. There will be multiple validations, such as :
The Vision System Communication should be validated if it is working as intended and in case of failure, the appropriate steps are followed. I.e., when the Vision System failed to send an "ALIVE" Signal into the PLC, the machine should stop (It is not possible in some cases i.e., in the extrusion process), or mention the operational staff about the occurring error. The operational staff can cut the wrong tube, and rewind it to another tube holder.
The Validation should consist of the simulations of possible failures during the process, which should be defined in the FMEA, or defined by the Quality Unit. Therefore, cooperation with the QA department is necessary.
Code Review is tricky. You will face multiple problems:is the programmer following the IEC 61131-3, Good Programming Practices, etc? Each programmer has their style of programming, so you need to have more time to solve their code purpose. Each Branch of the code should be checked for the proper function. The Assessment of the code can make it easier to focus more only on the critical parts of the code, which can affect the quality of the product, or patient safety. This approach should be mentioned in Code Review approach.
5. Other tests, which are based on the Risk-Assessment or Supplier Assessment.
Did your Risk-Assessment find more functions, that should be checked? I.e., Vision System parameters can be changed only with the?#appropriate?level, when it is set up? The following tests will consist of the?#User?#Access?#Tests, which will cover the user groups, add/modify/delete users from the application, obscured passwords, minimum password length, password aging, password expiration, revision, and many other tests, depending on your system?#application?functions.
Regulated companies are, however, responsible for ensuring the quality of the software and hardware, and the fitness for purpose of the computerized system when used in the GxP environment.
----------------
Bottom line:
The end-user should seek to benefit from supplier quality assurance processes and associated tests. It means, that if the supplier audit proves, that their quality system is appropriate and acceptable, the end-user can benefit from this audit, so no additional testing, which was covered by supplier?#QA?must be performed
You are welcome to subscribe to the?#CSV?/?#CSA?#Newsletter?to find more information from the Software / Control System?#Validation?world, where you will get some examples, of how to do it, which are proven and working. Also, you are welcome to comment, and post your point of view and approaches, because everyone is using different approaches for the Software / Control System Validation.
Best Regards,
Erik