If you have purchased or are planning to purchase a computer system for use in regulated activities, here are some key points to keep in mind. As the regulated company, your responsibilities differ from those of your vendor. There are examples from multiple regulatory documents regarding cloud and SaaS computer systems.
1. You are ultimately responsible (not the vendor)
As a regulated company, you need to approach the use of SaaS (PaaS, IaaS) systems similar to any other outsourced regulated activity.
Let’s look at what the FDA has to say regarding responsibility:
“The … manufacturer is responsible for ensuring that the product development methodologies used by the OTS (off-the-shelf) software developer are appropriate and sufficient for the device manufacturer’s intended use of that OTS software” – FDA, General Principles of Software Validation.
“Although much of the software validation may be accomplished by outside firms, such as computer or software vendors, the ultimate responsibility for program suitability rests with the pharmaceutical manufacturer.” – FDA, ORA Guide to Inspection of Computerized Systems in Drug Processing.
2. Limit the validation scope to the features you will use
You need to clearly document your intended use of the features in your User Requirements Specification. The scope of your validation can exclude any unused features, meaning that you don’t need any requirements or tests for them. For example, you subscribe to a SaaS system with document management functionality but don’t use it. You don’t need to validate the doc management features.
Configure your system to turn off all unused features. That would be ideal. If you cannot turn off features, determine a solution that ensures users do not start using the excluded features.
In the statements below from the FDA’s General Principles of Software Validation guidance document, you can see how they state that you can exclude unused system features.
“The device manufacturer retains the ultimate responsibility for ensuring that the production and quality system software: (1) is validated according to a written procedure for the particular intended use; and (2) will perform as intended in the chosen application.”
“For example, a device manufacturer who chooses not to use all the vendor-supplied capabilities of the software only needs to validate those functions that will be used and for which the device manufacturer is dependent upon the software results as part of production or the quality system”
3. Validation must be specific to your planned and documented use of the application
You must validate how you will be using the software. Write requirements and tests for how your company will use the system. Your vendor can confirm standard functionality (OQ), but they don’t know how your company will use the software (PQ).
For example: You don’t validate Excel when using the cloud version of MS Office, you validate the spreadsheets you build with Excel.
Here is where the FDA discusses validation for the intended use of your purchased system:
“All production and/or quality system software, even if purchased off-the-shelf, should have: (1) documented requirements that fully define its intended use, and (2) information against which testing results and other evidence can be compared, to show that the software is validated for its intended use.” – FDA, General Principles of Software Validation
The MHRA GMP Data Integrity Definitions and Guidance document states the following:
“The acceptance of vendor-supplied validation data in isolation of system configuration and intended use is not acceptable. In isolation from the intended process or end user IT infrastructure, vendor testing is likely to be limited to functional verification only, and may not fulfill the requirements for performance qualification.”
4. Systems from qualified vendors get less validation testing
When you build custom software, you are the first tester, so your validation should be extremely thorough. But for purchased systems, you have paid the vendor to do the thorough testing of every feature, every button, etc. Therefore, you should not need to do as much testing for purchased software. You are then able to focus your testing on the system’s suitability for your intended use.
NOTE: This does not apply to software from vendors that have not been audited or assessed. You cannot forego thorough validation simply because you purchased the system. But if you have audited your software vendor and are confident in the quality of their product and documentation, you can lessen the amount of testing.
“Commercially available software that has been qualified does not require the same level of testing” – ICH Q7A Good Manufacturing Practice Guide for Active Pharmaceutical Ingredients
“Records of software validation should be maintained by the drug establishment, although when conducted by outside experts such records need not be voluminous but rather complete enough (including protocols and general results) to allow the drug manufacturer to assess the adequacy of the validation. … Mere vendor certification of software suitability is inadequate.” – FDA, ORA Guide to Inspection of Computerized Systems in Drug Processing
5. Use vendor documentation as the starting point for validation
Vendors often provide or sell their Functional Specification and OQ testing documentation. You can use their supplied documentation in your validation, but you still need to have the User Requirements and perform PQ testing. You will also need to supplement the vendor’s FS/OQ documentation for any configured features.
Vendors have technical designs for the software. You need designs for the hardware (if self-hosting) and configuration. If you use vendor-supplied documentation, always document your acceptance and approval of this documentation.
For example: If you purchase a Training Management System, the vendor may provide the FS and OQ for standard functionality.
“Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled” – Eudralex Annex 11, Computerised Systems
“If the vendor can provide information about their system requirements, software requirements, validation process, and the results of their validation, the medical device manufacturer can use that information as a beginning point for their required validation documentation.” – FDA, General Principles of Software Validation
6. You need a documented assessment of vendor suitability
Assess the vendors you use for systems and services associated with regulated systems. You will also need documentation to show that you have assessed the qualification of the vendor or service provider.
Here are some quotes from the Eudralex Annex 11, Computerised Systems document:
“The regulated user should take all reasonable steps to ensure that the system has been developed in accordance with an appropriate quality management system.”
“The supplier should be assessed appropriately.”
The FDA makes the following statements in the 21 CFR 820 Quality System Regulation:
“Each manufacturer shall … ensure that all purchased … services conform to specified requirements.”
“Each manufacturer shall evaluate and select potential suppliers, contractors, and consultants on the basis of their ability to meet specified requirements, including quality requirements.”
“The evaluation shall be documented.”
7. For critical risk level systems, the regulated company may need to audit the vendors
You will need to audit vendors of your critical systems and IT services. The definition of a critical system will be specific to your company. These systems or services are usually those with direct impact to patients or products for patients.
This is explained by Eudralex in Annex 11, Computerised Systems:
“The need for an audit should be based on a risk assessment.”
“Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.”
Again, more examples from the FDA, this time in the General Principles of Software Validation guidance document:
“… depending upon the … risk involved, the … manufacturer should consider auditing the vendor’s design and development methodologies used in the construction of the OTS software.”
“The audit should demonstrate that the vendor’s procedures for and results of the verification and validation activities performed the OTS software are appropriate and sufficient…”
8. You must document responsibilities in your formal agreements
Formally document the responsibilities for you and your vendor. This applies to purchased software, SaaS and cloud systems. Your documentation should include the scope of your vendor’s services, such as:
- Providing the system
- System installation and integration
- Maintenance
- Retaining the system
You need to define responsibilities like back-ups, troubleshooting and bug fixes. Your agreements should also include notifications of any changes.
“Purchasing documents shall include, where possible, an agreement that the suppliers, contractors, and consultants agree to notify the manufacturer of changes in the product or service so that manufacturers may determine whether the changes may affect the quality of a finished device.” – FDA 21 CFR 820 Quality System Regulation
“When third parties are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party.” – Eudralex Annex 11, Computerised Systems
The Bottom Line
Whether IT services are provided in-house or by a third party, regulators have the same expectations: you, as the regulated company, are responsible. That means if your services are outsourced, you must ensure that your vendor is working at the same standard you expect of an internal IT group. After all, you will need to prove this in an inspection.
Author
Deb Bartel
