1. Ques: when leveraging vendors' documentation, for example SAT testing leveraging into qualification, what are the main principles to be in place.
Ans: Take your VMP requirements for the validation of that piece of equipment, subtract those SAT-satisfied tests, and develop test cases for the remainder, including any SAT tests that may be negatively impacted by actions upon the equipment since the SAT was performed, e.g., movement / transport, installation ... I've done this many times and had no push-back from regulatory agencies. In fact it's specifically mentioned in ASTM E 2500 as an acceptable / preferred method.
2. Ques: what are the main principles with bracketing/family approach testing?
Ans: It would depend on the equipment family we're talking about (its complexity, inherent variability and end user risk). As I mentioned in the webinar, I'm not much of a believer in Like-for-like, due to inherent variability in any equipment's manufacturing process. But anything that is not (or minimally) subject to such variability, such as the equipment's software / firmware, in differing serial numbers of the same model of equipment, having the same software rev. no. / release no., could be considered, and those remaining / hardware elements, of minimal variability (based on data, or to a lesser degree, a priori considerations), if also low risk to the end user / patient, could be considered.
Usually this "consideration" would mean that the validation of the 2nd , 3rd ... iteration of the "same" type of equipment, would be much reduced in possible number of test cases, number of elements in each test case, reduced test case sample sizes (PQs), the numbers of PQs run, degree of repetitive descriptive documentation, etc., ... in subsequent validations compared to the first (of course, with cross-references in subsequent related validations to the initial validation).
Usually this "consideration" would mean that the validation of the 2nd , 3rd ... iteration of the "same" type of equipment, would be much reduced in possible number of test cases, number of elements in each test case, reduced test case sample sizes (PQs), the numbers of PQs run, degree of repetitive descriptive documentation, etc., ... in subsequent validations compared to the first (of course, with cross-references in subsequent related validations to the initial validation).
In some / many cases the issue falls into a grey area, and it might be wise to validate, rather than try to develop a rationale and defend that rationale repeatedly with all stakeholders / inspectors, with the strong possibility after all that you could still lose the argument with a regulatory agency and have to validate anyway (been there, done that).
jel@jelincoln.com
No comments:
Post a Comment