A Risk-Based approach for Software Category 3

This article will cover a Risk-Based approach for Category 3 Devices, which includes devices, that can be mostly known under different names, such as #Canned, #COTS (Commercial-OFF-THE-SHELF), or #OTS (OFF-THE-SHELF) #Devices.

Category 3 Definition:

Category 3 covers commercially available, standard #software packages, and "OFF-THE-SHELF" solutions for certain processes. It includes both systems that cannot be configured to conform to business processes and #systems that are configurable but for which only the default configuration is used. The #configuration of these software packages should be limited to adaptation to the #runtime environment, i.e., network, and printer connections.

Category 3 Used Nowadays:

In #Medical Devices, or the #Pharmaceutical industry, nowadays most of the software and hardware Control Systems are based on purchased COTS products, rather than being bespoke / Custom built. Medical Devices, Pharmaceuticals, and many other regulated healthcare companies are accountable to the #regulatory authorities for ensuring that the product methodologies used by the COTS developer are of a sufficient degree of capability, maturity, and adequate for the intended use of the COTS product. Commercial Software products may have a "Bug List", #user manuals, and product specifications that can be compared with the user requirements to structure such #black box #testing efforts.

Functional testing or Black-Box is based on testing the system from a user′s perspective, without knowledge of the internal architecture and structure of the system.

Category 3 Typical Issues:

The issue that can occur with COTS #products is that access to product development documentation may not be available. The #suppliers may refuse to share their proprietary information, or it may be unavailable for some other reason. Therefore, the Functional and #Design Specifications are not expected from the user, although there should be sufficient specifications to enable testing (Typically covered by the #URS and other relevant documentation).

Another issue, that can occur with COTS products is #upgrades of the software packages, where the official output document, what was upgraded is missing, or not available from the supplier. The supplier should write the differences between the older Software version and the newer software version.

A Risk-Based approach for Category 3?

First, you need to 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 3 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. Testing, that demonstrates the fitness for the intended use of the device,

Your device was purchased, to test the tube length, inspect the tube gloss, inspect its diameter, or everything at once? You need to validate your system, that all of these requirements are working. I.e., Tube length testing will consist of these #tests, Tube length acceptance (minimum, maximum), missing tube in feeding, missing tube during the process, and other additional tests, which were found during the #risk #assessment, or other #regulatory requirements.

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

----------------

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