Skip to main content

1.1 QMS Scope, Process Map & Mandatory Records

A Quality Management System (QMS) without defined boundaries becomes a bureaucracy engine. We define scope not to satisfy auditors, but to focus engineering resources on failure prevention rather than administrative overhead. If a process affects product safety, reliability, or regulatory compliance, it is controlled. If it does not impact the physical product or user risk, it remains outside the system to preserve agility.

Determining QMS Scope

Define the boundary based on risk and product impact. Do not encompass the entire organization.

Decision Logic: In-Scope vs. Out-Scope

  • IF process alters Form, Fit, or Function of the device (e.g., PCB Layout, Firmware Commit, Supplier Selection) -> THEN Process is Controlled (In-Scope).
  • IF process generates data used for product validation or release (e.g., QA Testing, Metrology) -> THEN Process is Controlled (In-Scope).
  • IF process is purely administrative (e.g., Payroll, Finance, Office Management) -> THEN Process is Uncontrolled (Out-of-Scope).

Pro-Tip: Never exclude "Outsourced Processes" from scope. If a Contract Manufacturer (CM) builds the PCBA, the "Management of Outsourced Processes" is a critical internal control. You cannot outsource liability.

The Process Map (Interaction of Processes)

The QMS is a system of linked pipes, not a pile of silos. Inputs must equal outputs.

Core Architecture:

  1. Input (Requirements): Market needs convert into System Requirements Specifications (SRS).
  2. Transformation (Realization):
    • Design Control: Converts SRS into Technical Specifications (Gerbers, Schematics, BOM).
    • Production: Converts Technical Specifications into Physical Goods.
  3. Output (Delivery): Verified product reaches the customer.
  4. Feedback (Loop): RMA and Complaint data feeds back into Design Inputs for the next revision.

Linkage Rules:

  • IF Design Transfer is incomplete (e.g., missing Assembly Instructions) -> THEN Production Halis. Do not rely on tribal knowledge.
  • IF Non-Conformance (NC) rate > Trigger Limit -> THEN CAPA process Initiates automatically.

Mandatory Records (Evidence of Control)

Records are not generated for the auditor; they are generated to enable Root Cause Analysis (RCA) 5 years from now. If it isn't written down, it didn't happen, and the batch is suspect.

Traceability Hierarchy:

  • DHF (Design History File): Why we built it. (Contains: SRS, Risk Analysis, Design Reviews).
  • DMR (Device Master Record): What we build. (Contains: Approved BOM, Gerbers, SOPs).
  • DHR (Device History Record): How we built this specific unit. (Contains: Serial Numbers, Test Logs, Rework Notes, Date Codes).

Retention Policy:

  • IF Product Lifecycle is X years -> THEN Retain records for X + 2 years (or as required by local law, whichever is longer).
  • IF Record pertains to Safety Critical Component -> THEN Retain Indefinitely.

Pro-Tip: Digitally sign records at the moment of creation. Retroactive signing (backdating) is fraud and destroys data integrity.

Final Checklist

Control Point

Critical Requirement

Non-Negotiable Rule

Scope Boundary

Exclusions must be justified (e.g., "We do not service").

Do not claim "Design" exclusion if you modify firmare.

Process Interaction

Outputs of A must meet Inputs of B.

No "Throw it over the wall" handoffs.

DHR Integrity

Full traceability to component lot level.

Missing serial number = Scrap the unit.

Record Retention

Retrieveable within 24 hours.

Backups must be tested quarterly.

Change Control

Revision history on all DMR docs.

No uncontrolled "Redline" changes on the production floor.