Wednesday, November 23, 2016

COTS (Commercial Off The Shelf) Software Question / Answer

Ques: We are in the process of validating a capital equipment, it is a class II medical device. It includes both software and hardware.  The software component is not separable and is not accessible/modifiable but it is the major interface that user can configure/run the device and monitor some parameters. The software also will raise alarms when there is an undesirable situation/risk to the patient. The device was developed overseas and is not have FDA approved.  We were not involved in the validation practices during the design and development of the software, nor we have access to the vendor’s codes and majority of their documentation.  During the webinar you talked about the IQ/OQ/PQ approach in validation of the software. Under the circumstances, is it acceptable to use IQ/OQ/PQ approach as the only validation practice in a 510K FDA submission without any other type of software validation activity/documents?

Ans:  Yes.  The webinar addressed primarily this final stage, integrated / systems level software validation.  You would do a "black box" V&V (verifying software operation by means of the hardware's operation) of hardware and software using IQ, OQ, PQs as described*, but include any information you know about the development methods and in-process test methods used in the development of the custom software.  
Alarms are a particular issue with the FDA.
You would have to use the guidance document I cited, as its required for a submission to the FDA, and compile the 11 documents for your submission (while all are filled out and part of your DHF, not all will be submitted as determined by Level of Concern).  
Where you cannot obtain the necessary information from the vendor, that would be stated under the applicable document, e.g, Design Spec, and Development.  Whatever you can supply, should be included (from any tech manuals, Wikipaedia, web site info, verifiable, etc.).
This is a typical approach with COTS software where you don't have access to the code.

*  IQ -- Software requirements met by hardware; installed properly;
OQ -- Software initializes and shuts down properly. Required features exist and function. Any settings are optimized. 21 CFR 11 issues addressed, exist, operate, if applicable
PQs -- Repeatability and reproducibility of applicable requirements, e.g., screen outputs, alarms, etc, are challenged by worst case runs, multiple samples per run. 

-- John E. Lincoln
COTS (Commercial Off The Shelf) Software Question / Answer

Ques: We are in the process of validating a capital equipment, it is a class II medical device. It includes both software and hardware.  The software component is not separable and is not accessible/modifiable but it is the major interface that user can configure/run the device and monitor some parameters. The software also will raise alarms when there is an undesirable situation/risk to the patient. The device was developed overseas and is not have FDA approved.  We were not involved in the validation practices during the design and development of the software, nor we have access to the vendor’s codes and majority of their documentation.  During the webinar you talked about the IQ/OQ/PQ approach in validation of the software. Under the circumstances, is it acceptable to use IQ/OQ/PQ approach as the only validation practice in a 510K FDA submission without any other type of software validation activity/documents?

Ans:  Yes.  The webinar addressed primarily this final stage, integrated / systems level software validation.  You would do a "black box" V&V (verifying software operation by means of the hardware's operation) of hardware and software using IQ, OQ, PQs as described*, but include any information you know about the development methods and in-process test methods used in the development of the custom software.  
Alarms are a particular issue with the FDA.
You would have to use the guidance document I cited, as its required for a submission to the FDA, and compile the 11 documents for your submission (while all are filled out and part of your DHF, not all will be submitted as determined by Level of Concern).  
Where you cannot obtain the necessary information from the vendor, that would be stated under the applicable document, e.g, Design Spec, and Development.  Whatever you can supply, should be included (from any tech manuals, Wikipaedia, web site info, verifiable, etc.).
This is a typical approach with COTS software where you don't have access to the code.

*  IQ -- Software requirements met by hardware; installed properly;
OQ -- Software initializes and shuts down properly. Required features exist and function. Any settings are optimized. 21 CFR 11 issues addressed, exist, operate, if applicable
PQs -- Repeatability and reproducibility of applicable requirements, e.g., screen outputs, alarms, etc, are challenged by worst case runs, multiple samples per run. 

-- John E. Lincoln

Monday, November 21, 2016

Cut Down  on  Team  Meetings

Require of your team members --
Completed Staff Work”  (U.S. Military;  also see Leon Shimkin, GM then owner, Simon and Schuster, from “… Stop Worrying…”, by Dale Carnegie):
      What is the problem?
     What is the cause of the problem?
     What are all the possible solutions to the problem?
     What solution do you suggest (with rationale)? 

See also my website on the subject:


-- John E. Lincoln