A Risk-Based approach for Software Category 4

In previous articles in 2022, I wrote about a Risk-Based approach for Software Category 1, and Software Category 3 devices. If you missed these articles, you are welcome to check them out before reading them to gain more knowledge about this categorization and approach for each category. This article will cover the Configurable packages, which as known in #GAMP? 5 as Category 4.

Category 4 Definition:

This category defines #COTS packages, or "custom configurable packages", whose configuration makes use of standard calculations and predefined control routines. Configurable software products provide standard interfaces and functions that enable the configuration of user-specific business processes. This typically involves configuring predefined software modules. Examples of Category 4 are typically Process Control Systems (PCS), Supervisory Control and Data Acquisition Systems (#SCADA), #MES, LIMS, or MRP packages. These #software packages should only be considered as category 4 if they are well-known and fully developed, otherwise, category 5 is applicable.

Category 4 Typical Issues:

As this category permit #client to develop their application by configuring/amending predefined software modules and also to develop new application software modules, the typical issue is, if they will handle them as category 4, or category 5 and how about its documentation. This question is the most common. The answer is #simple and straight - it should be handled as category 5. In case, that the machine is newly purchased, the creation of configurable #packages typically involves code written by the supplier. Therefore, the supplier should follow a full product development life cycle. In case, that the machine is out of warranty, and the code is written by an internal #programmer, the regulated company should cover the requirements of the full product development cycle, or handle the changes through change management.

The second most known question is if the regulated company should test the whole system, especially functions, which are not related to their business or are not used in production. In case, that the #supplier has a suitable and adequate quality management system in place and the package is "#standard" ( standard - it was not being developed or modified specifically for the User application ), the user does not need to repeat testing already carried out by the supplier. The application life-cycle test activities can be #limited to those which verify that the configuration has been correctly implemented such that the overall system performs as defined in the User Requirement Specification. #Risk assessment should consider the need to test functions within the system that the user does not intend to utilize to ensure that there is no inadvertent interaction with the required functionality.

The third, most common typical issue is, that the #Functional Specifications (FSs) may not be owned by the user, there should be adequate specifications available to ensure traceability and adequate #test coverage. This will be very helpful and serve as guidance for the future testing of the device.

A Risk-Based approach for Category 4?

First, as in the approach for the category 3 system, the user should have a User Requirements Specification, or some specification from the supplier, where you will prepare the?#tests?against these specifications and your requirements. These tests will help the end user, to perform selected tasks and validate the selected system for the intended use. The?#validation?should be with a?#Risk-Based approach, where the simple, or functions, which do not affect the product or patient safety should be avoided, and justified, that they don't have any risks related to the?#product?quality or?#patient?safety.

The typical approach for the category 4 devices is:

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. 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.

3. Testing, that demonstrates the fitness for the intended use of the device,

I will continue with the previous example, where in category 3 I wrote about the device, which is measuring the tube length, inspects the tube gloss, and inspects its diameter.

But,

The #management is required to add additional types of tubes, with #different diameters, where the #barcode scanner is also added to scan the material.

Besides the tests which were performed in the previous case, new tests should be performed. The new test should cover all new requirements, where the testing will cover the different tube diameters ( i.e., 10, 12, 14, 16 ), and also the barcode reader function. To not #overwhelm yourself, or your engineers, the test should be supported by Risk-Assessment, as it was mentioned before. I.e., #testing of the barcode reader ( reading the Data Matrix ) is not necessary to perform on each tube diameter, but it is enough to perform once, as the reading is the same for each tube #diameter. Step by step you will simplify your testing methods.

Each configuration testing should be mentioned, evidenced, and validated.

4. Other tests are based on the Risk-Assessments or Supplier Assessments.

Did your Risk-Assessment find more functions, that should be checked? I.e., parameters of the machine 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