Instrument Design Qualification (DQ) Protocol

This is a ready-to-use design qualification (DQ) protocol for a laboratory instrument. DQ is the documented check, done before you buy or build, that the instrument you intend to acquire is fit for its intended use and that a supplier capable of supporting it has been selected. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the user requirements and supplier evidence, and route it through your normal document control, review, and approval. A worked filled specimen for an HPLC follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This protocol defines how <<FILL: COMPANY NAME>> confirms, before purchase, that the proposed <<FILL: instrument type>> and its supplier meet the documented user requirements and are fit for the intended use described in section 4. DQ closes the front end of the qualification lifecycle: it links the intended use and user requirements to a specific make and model and a specific supplier, and records the rationale for that selection so that installation, operational, and performance qualification have a defensible starting point.

2. Scope

This protocol applies to the single <<FILL: instrument type / make / model>> to be installed at the laboratory named in the header, including its instrument control and data system where that software is supplied with the instrument. It covers intended use, user requirements, supplier capability, the technical specification of the proposed model, and the fitness-for-purpose comparison that supports the acceptance decision. It does not cover installation qualification, operational qualification, performance qualification, or computerized system validation of the data system, which are governed by <<FILL: cross-reference protocol / SOP-IDs>>. Where the instrument carries software, this DQ records the software category and risk; detailed software validation follows the approach in <<FILL: CSV / CSA SOP-ID>>.

3. Responsibilities

4. Intended use

State the intended use in concrete, testable terms. Vague intended use is the single most common reason a DQ fails to defend a later purchase, because nothing downstream can be traced back to it.

5. User requirements

User requirements are the formal, numbered, testable statements the instrument must satisfy. They are the contract DQ checks the proposed model against and the source IQ, OQ, and PQ trace back to. Record them in the linked URS and summarize the critical ones here. Classify each as a regulatory, operational, or performance requirement, and mark each as mandatory (must) or desirable (should), so the acceptance decision is not held hostage by a nice-to-have.

6. Supplier assessment

DQ records that the supplier can deliver and support the instrument over its life, not only sell it. The depth of assessment is risk-based: a low-risk bench instrument from an established vendor may need only a documented review of public information, while a high-risk system or a configured/custom data system warrants a questionnaire or an audit. State the basis for the depth you chose.

6.1 Supplier capability record

6.2 GAMP software category (if instrument carries software)

Record the software category so the validation effort downstream is proportionate. Most analytical instrument control and data software is GAMP Category 4 (configured) or a mix of Category 3 (non-configured/standard) and 4.

7. Technical specification selection and fitness-for-purpose comparison

This is the technical heart of DQ. For each user requirement, record the supplier-stated specification of the proposed model and the verdict on whether it meets the requirement. Where you are unsure, do not write “meets”; record “to verify at OQ” and carry it into the OQ protocol so the gap is closed with evidence, not assumed away. Cite the source of each supplier specification (datasheet revision, quotation, or written supplier confirmation) so the comparison is verifiable.

For any verdict that is not a clean “Meets”, record the disposition in section 8.

8. Gaps, risks, and dispositions

List every requirement not cleanly met by the proposed specification, the risk it carries, and how it is handled. A gap is acceptable only with a documented disposition; an unhandled gap blocks acceptance.

9. Acceptance criteria

DQ is acceptable, and the purchase and downstream qualification may proceed, only when all of the following are true:

• The intended use (section 4) is stated in concrete, testable terms.
• Every mandatory user requirement is documented, numbered, and testable in the linked URS.
• Every mandatory requirement is either met by the proposed specification or carries a documented disposition that closes the gap downstream, with nothing left unhandled.
• The supplier is on the approved list or has been qualified at a depth justified by risk, with the evidence referenced.
• Where software is supplied, the GAMP category is recorded and the records and signatures features in scope are identified.
• The acceptance decision, with rationale, is recorded and approved by the user and Quality Assurance.

10. Acceptance decision

11. References

USP <1058> Analytical Instrument Qualification (defines the DQ/IQ/OQ/PQ framework and instrument groups A, B, C). 21 CFR 211.63 and 211.68 (equipment design, suitability, and automatic/electronic equipment). 21 CFR 211.160(b) (laboratory controls scientifically sound). 21 CFR Part 11 (electronic records and signatures), where the data system creates regulated records. EU GMP Annex 11 (computerised systems) and Annex 15 (Qualification and Validation), 2015 revision. ICH Q9, Quality Risk Management (for the risk-based depth of supplier assessment and qualification). ISPE GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (software categories and supplier assessment). ISO 9001 (supplier quality management), and ISO 13485 where the instrument supports a medical-device process.

Confirm the current version and clause numbers of each reference before issue.

12. Attachments

13. Revision history

14. Approvals

Filled specimen

The following shows the requirements, supplier, and specification-comparison sections completed for an example quaternary HPLC system intended for GMP release testing, so you can see the level of detail an inspector expects. The company, supplier, model, and numbers are illustrative; replace them with your own.

Intended use: Quantitate assay and related substances of small-molecule drug products by reversed-phase HPLC, running compendial and validated in-house gradient methods, GMP release and stability testing, high data criticality, producing chromatograms and integration results subject to 21 CFR Part 11.

In this specimen the team wrote a concrete intended use, traced each mandatory requirement to a published specification, refused to write “meets” for the carryover figure the datasheet did not state, and instead carried it forward to OQ as a tracked open item. They classified the data system as GAMP Category 4 so the software effort downstream would be proportionate, and set the supplier-assessment depth from the instrument’s risk rather than auditing reflexively. That sequence, intended use to requirements to specification comparison to dispositioned gaps to an approved decision, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this protocol prevents

• An instrument purchased and qualified with no DQ, so no record links the chosen model to a defined intended use or to user requirements.
• User requirements written as marketing statements, not numbered testable criteria, so IQ/OQ/PQ cannot trace back to anything.
• “Meets requirement” recorded against specifications the datasheet never stated, with no verification planned.
• No supplier assessment at all, or an identical full audit applied to every instrument with no risk basis, neither of which an inspector accepts.
• Software supplied with the instrument never categorized, so the data system reaches GMP use without proportionate validation of audit trail, access control, and Part 11 features.
• Gaps spotted at DQ that quietly disappear instead of being carried as tracked open items into OQ, PQ, or CSV.
• DQ approved by the validation author alone, with no user confirmation of fitness for purpose and no QA approval.

How to adapt this protocol

1. Set your document number, owner, linked URS number, and downstream IQ/OQ/PQ references in the header.
2. Rewrite the intended use in section 4 in concrete, testable terms for your instrument and its actual GxP use and data criticality.
3. Replace the user requirements in section 5 with your real numbered URS items, classified and marked mandatory or desirable, and keep the URS as Attachment 1.
4. Set the supplier-assessment depth in section 6 from the instrument’s risk and the USP <1058> group (A, B, or C); record the GAMP software category only if the instrument carries software.
5. Fill the specification comparison in section 7 from the actual datasheet revision and quotation, and carry every non-clean verdict into section 8 with a disposition that points at OQ, PQ, or CSV.
6. Confirm every regulation in section 11 against the current published version before issue.