A Risk-Based approach for Software Category 1
As I mentioned in a previous article about the?Software Design Specification?#GAMP5?recognizes that software commonly used in computerized systems can be divided into four (4) types. These categories can then be used as a basis for determining an appropriate validation approach.
In this article, I will describe the approach for the?#software, classified as category 1.
Category 1,
#Standard,?#commercially?available operating systems that are used in?#pharmaceutical,?#medical?device?#production?are considered validated when they are used in projects where the application software that runs on this platform is included in the validation process - i.e., the operating system itself is not directly validated, rather, it is?#validated?as a part of the application that runs on it. This does not preclude auditing activities related to software development of the?#operating?system. Reputable operating systems must be used, and the operating systems name and?#version?must be recorded in the equipment?#IQ. New versions should be reviewed prior to use and consideration given to the impact of new, amended, or removed features on the application. Findings from this?#review?could lead to a formal re-testing program of the application, particularly where a major upgrade of the operating system has occurred.
#Risk-Based approach for Category 1?
As it was mentioned earlier, the new implementation of OS, or database engines should be reviewed prior to use, and consideration given to the impact of new, amended or removed features on the OS.
So, the Risk-Based approach will look like below pictured, Where all three types of Action priorities are pictured, and different approaches are selected.
领英推荐
Action priority M
#Upgrading?Windows can affect the whole application running on the system (such as?#communications, or?#data?#integrity), the calculated Action Priority is "M", which means, that the identified potential failure has been identified with high severity. High severity means potential loss of critical data. Therefore, the testing should be performed on the whole application running on the OS. The new OS name and version must be evidenced
Action priority L
Update the application #User Interface (New Logo) on Windows Login Screen, where the calculated Action priority is "L", which means, that the identified potential #failure has no risk or the controls in place are sufficient. In that case, no potential failure can occur by implementing a new logo on #Windows Login.
Action priority H
Updating the #Bluetooth drivers can affect the application communication with other systems, such as #RFID readers, the calculated Action Priority is "H", which means the identified potential failure requires an action to reduce or eliminate the related risk. This risk can be reduced, or related via a #change #management record, where the formal re-testing of the affected application functions (#Communication, data collection) will be performed, with evidence that the process after updating the driver is working as intended.
With this Risk-Based approach, you can make your testing decision easier, more cleaner, with a focus only on critical parts of the change, or system, which can affect the product quality, data integrity, or patient safety.
CSV Consultant / Quality Assurance
2 年There are a lot more systems/tools that are considered as Category 1 than the OS as defined in the GAMP 5 handbook, notably Excel spreadsheet and middleware (we can go to wiki to check, even content management systems are included). Still others are sw that supports applications themselves such as for code review, test automation, deployment and releases. So these form a layer below applications themselves. By Annex 11 speak, they should be "qualified' rather than validated. In GAMP5, the rigor of testing is pretty low, usually none. It's mostly activities such as security management, incident management, change management, configuration management that applies, so they mostly follow good IT practices as defined in ITIL.