A reader asked a question re: "Design Qualification", as in DQ, IQ, OQ, PQ. "This is a term I am not
familiar with. I have not seen it in 21 CFR and could not find any references on FDA.Gov. I also do not remember seeing it in 13485. I would like more clarification and examples, also to understand where this requirement comes from."
To
answer the question: Go to www.fda.gov and search IQ OQ
PQ. You will not find DQ or Design Qualification. However, you will find guidance documents on software V&V and process V&V
that discuss the terms, define them, and state the FDA's requirements for their
use. And IQ, OQ, PQ presuppose proper requirements against which the IO, OQ, and PQ test cases would be developed to prove the Requirements have been proven to exist and function as expected.
If you enter "DQ validation" or "Design Qualification" into Google, you will find definitions similar to the one I give below.
The "c" in CGMP means that 21 CFR XXX is the rock bottom minimum they require, but that they expect companies to use practices in their industry that are "c" or "current". IQ, OQ, and PQ have been around for decades. DQ is less frequently used, but it is still used somewhat frequently in FDA regulated industries. DQ generally means verifying that user / functional requirements are valid and complete. it is an additional step after development of the Requirements, to ensure no valid requirement is missing, including applicable standards and/or guidance documents. While this is often done "intuitively", such a DQ action should be documented, since an auditor or other reviewer would expect that Requirements are somehow qualified or verified for appropriateness / completeness.
If you enter "DQ validation" or "Design Qualification" into Google, you will find definitions similar to the one I give below.
The "c" in CGMP means that 21 CFR XXX is the rock bottom minimum they require, but that they expect companies to use practices in their industry that are "c" or "current". IQ, OQ, and PQ have been around for decades. DQ is less frequently used, but it is still used somewhat frequently in FDA regulated industries. DQ generally means verifying that user / functional requirements are valid and complete. it is an additional step after development of the Requirements, to ensure no valid requirement is missing, including applicable standards and/or guidance documents. While this is often done "intuitively", such a DQ action should be documented, since an auditor or other reviewer would expect that Requirements are somehow qualified or verified for appropriateness / completeness.
If you choose to follow ASTM E2500,
then you won't necessarily use these terms, but are still expected to perform what they
stand for. All US FDA investigators / notified-body auditors (ISO 13485 ...) expect the same.
In order
to properly validate equipment, software, processes, you would have to do them
(Rqmts. / DQ, IQ, OQ, PQs, or identical equivalents / activities). The principles are not optional, i.e.,
you have to prove you installed X correctly / per spec (IQ against DQ / Rqmts
Specs), you set it up and optimized parameters (e.g., DOE) for X correctly (OQ
against DQ/Rqmts Specs), and you proved that X ran repeatedly, over extended
periods of time, with varying conditions / inputs ("worst case"
conditions / inputs), robustly (PQs against DQ/Rqmts Specs, 3 or more runs).
So, while the acronyms can vary, the activities they represent cannot.
-- John E. Lincoln, jelincoln.com
-- John E. Lincoln, jelincoln.com
No comments:
Post a Comment