Chapter 1 · Events, material review and holds
One record for every quality event
A quality system is only as good as its ability to connect things: the nonconforming lot, the customer complaint, the audit finding and the supplier that caused them. This chapter says what Quality management builds, the standards it is measured against, and the three ideas at its centre: one record model for every event, a signed material review decision, and holds that actually stop product.
25 min7 event types6 dispositions1 enforced hold rule
By the end of this chapter you can
- Say what the module does, what it leaves to other modules, and what its capability tiers mean.
- Explain why every kind of quality event lives in one supertype table with small detail tables.
- Name the six material review dispositions and say what each does to the lot and its hold.
- Explain the difference between an advisory flag and a hold that is enforced in the database.
What Quality management does
The module manages quality events end to end: nonconformances and material review, deviations, complaints, CAPA (corrective and preventive action) with root cause and effectiveness checks, audits, change control, risk in the form of FMEA (failure mode and effects analysis), and supplier quality. All of it sits on one record model, with holds that stop product. It replaces the electronic quality management system (eQMS) a business usually pays for: MasterControl, ETQ Reliance, Veeva Vault QMS, TrackWise, Intelex, Qualio, Greenlight Guru, QT9 or Ideagen Quality [5][6].
Its tables share the prefix qms_. Like every module on the platform it has no people list, site list, item list or file store of its own: it points at the shared spine (core_person, core_site, core_item, core_lot, core_equipment, core_party, core_attachment, core_e_signature and others), so a quality event about a lot is a row that points at the same lot every other module uses.
- In: the quality event supertype with NCR, deviation, complaint, audit finding and supplier corrective action request (SCAR) subtypes; material review board (MRB) disposition and quality holds on lots, orders or equipment; CAPA with 8D, 5-Why, fishbone and A3; internal, supplier and regulatory audits; change control with impact assessment; FMEA with the AIAG-VDA action priority; approved supplier list, scorecards and PPAP status.
- Out: the document lifecycle (M06), training records (M07), SPC charts and capability (M09), and the engineering change of product definitions (M14 ECO, which links to a change request here).
Eleven capabilities in three tiers
Each capability carries a tier. MVP must exist for a small or mid-size business to cancel the incumbent subscription with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class differences, such as those made possible by AI.
| Capability | What it does | Tier |
|---|---|---|
| Quality events | Unified intake from forms, MES, SPC, LIMS, customers and suppliers; severity; triage; ownership; due dates; full status history | MVP |
| NCR and MRB | Quantity affected, defect codes, containment, MRB disposition with approvals, cost of poor quality captured | MVP |
| Quality holds | Hold lots, orders, equipment or suppliers; holds enforced in M04, M12 and M13; release with a signature | MVP |
| CAPA | Problem statement, containment, root cause tools, actions by type, effectiveness criteria and verification, overdue escalation | MVP |
| Complaints | Customer complaint intake, RMA link, investigation, reportability assessment, response letters | STD |
| Deviations | Planned and unplanned deviations with impact assessment and batch linkage | STD |
| Audits | Audit programme, schedule, checklists by standard clause, findings that become events and CAPA, audit reports | STD |
| Change control | Change request, classification, impact assessment across documents, training, validation and regulatory, approvals, tasks, effectiveness review | STD |
| Risk and FMEA | Design and process FMEA, severity, occurrence and detection, action priority, recommended actions | STD |
| Supplier quality | Approved supplier list, qualification, SCARs, scorecards (ppm, on-time delivery, responsiveness), PPAP tracking | STD |
| Analytics and AI | Cost of poor quality, trend detection, recurring-issue clustering, AI triage and CAPA draft suggestions with human approval | BIC |
The standards, and what each is used for
| Standard | Used in this module for |
|---|---|
| ISO 9001:2015, clauses 8.7, 10.2, 9.2 and 9.3 [1] | Nonconforming outputs, corrective action, internal audit and management review |
| IATF 16949:2016 with the AIAG Core Tools | APQP, PPAP, FMEA, MSA and SPC requirements for automotive |
| AIAG-VDA FMEA Handbook (2019) | The seven-step FMEA and the action priority (H, M, L) that replaces ranking by RPN alone |
| ISO 13485:2016, FDA QMSR (21 CFR Part 820, effective 2 February 2026) and ISO 14971:2019 [2][3] | Medical device quality systems, complaint handling and risk management |
| ICH Q9(R1) and ICH Q10 | Pharmaceutical quality risk management and the pharmaceutical quality system |
| 21 CFR Part 11 and EU Annex 11 [4] | Electronic records and electronic signatures |
| AS9100D | Aerospace quality systems: nonconformance and first-article linkage |
One supertype for every event
Every quality event, whatever it is called on the floor, is a row in qms_quality_event: an NCR (nonconformance report), a deviation, a complaint, an audit finding, a SCAR, an observation or an out-of-specification (OOS) result. The row carries what every event needs: an event number, a type, a title, a severity, a status, an owner, a due date, and pointers to the site, item, lot, equipment, supplier and customer it concerns. Three kinds need extra fields, which live in small detail tables that point back at the event.
| event_type | What it is |
|---|---|
| ncr | A nonconformance: product or process output that does not meet its requirement |
| deviation | A planned or unplanned departure from an approved procedure or specification |
| complaint | A customer complaint, with channel, RMA and a reportability decision |
| audit_finding | The result of an audit checklist item that was not conform |
| scar | A supplier corrective action request |
| observation | Something noticed that is not (yet) a nonconformance |
| oos | An out-of-specification result, for example from a laboratory system |
Severity is one of critical, major, minor or observation. Events arrive from forms that failed an item (frm.response.failed), SPC violations (spc.violation.detected), laboratory out-of-spec results (lims.result.oos), machine parameters out of spec (mes.parameter.out_of_spec), calibrations out of tolerance (cmms.calibration.out_of_tolerance) and customer service tickets (svc.ticket.complaint). Each carries source_type and source_id, and a retry from another module must create no second event.
Knowledge check
Why do NCRs, complaints and audit findings share one table, qms_quality_event?
Material review: a signed decision
An NCR adds a row in qms_ncr_detail: the quantity affected and its unit, the defect code (from the defect taxonomy in qms_defect_code), the containment taken, the cost of poor quality, and the disposition. The material review board decides the disposition, which is one of six values; until it is decided it is pending.
The decision needs an electronic signature: a core_e_signature row with its meaning, the signer, the time and a hash (a fingerprint) of what was signed. A disposition other than pending without a signature and a decision time is refused by the database. The signer is not the person who reported or owns the event, so nobody approves their own work. 21 CFR Part 11 sets out what such signatures must carry [4].
Cost of poor quality (COPQ) is captured on the same row: the module adds up scrap, rework, returns and concessions cost per period. It is the number that tells a manager what the problems cost, and it is only as good as the NCRs entered.
Holds that stop product
A hold in qms_hold blocks a lot, production order, equipment, supplier, item or location (the target_type), for a reason, placed by a person at a time, optionally linked to the event that caused it. Its status is active, released or converted_to_scrap. Releasing needs a signature.
You need: Read access to your eQMS or quality log, a text file, and the quality manager for five minutes
Use the records your business has today. Do not copy customer, patient or employee names: record only the type, severity and status.
Outcome: A ten-line table of event type, severity, status and hold, and a count of how many records are split across lists today.
Knowledge check
What makes a hold different from an advisory flag?
References
- ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html
- ISO 13485:2016, Medical devices: quality management systems. https://www.iso.org/standard/59752.html
- 21 CFR Part 820, Quality System Regulation and QMSR (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
- 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
- Prezent: eQMS platforms for life sciences. https://www.prezent.ai/blog/qms-for-life-sciences
- SoftwareConnect: Veeva Vault QMS. https://softwareconnect.com/go/veeva-vault-qms-29564
Chapter 2 · Finding the cause and proving the fix
Corrective action, audits and change control
Containing a problem is not the same as solving it. CAPA finds the cause, changes something so it does not return, and then checks that the change worked. Audits find problems before customers do, and change control makes sure a fix does not create a new problem somewhere else.
25 min7 CAPA statuses3 gates8 change types
By the end of this chapter you can
- Walk a CAPA through its statuses and say what each of the three gates refuses.
- Choose a root cause tool (5-Why, fishbone, is/is-not, fault tree, Pareto, timeline) and say where its content is stored.
- Explain how an audit result becomes a finding and then a CAPA, and why auditors must be impartial.
- Describe the change control path and what must be true before a change is implemented and closed.
CAPA: cause, action, proof
A CAPA record (qms_capa) starts from a problem, often an event, and keeps one story from the problem statement to the signed closure. It holds the origin event, the problem statement, the method (eight_d, five_why, a3, dmaic or other), the containment, the root cause and its category, the owner, the due date, the effectiveness criteria and the effectiveness result. ISO 9001:2015 clause 10.2 asks for exactly this chain on a nonconformity: react to it, find out whether similar ones exist or could occur, review and determine the cause, implement the action needed, review its effectiveness and update risks if necessary [1].
Root cause tools
Each tool is a row in qms_rca_artifact, with its content kept as JSON because the shape of a fishbone differs from a timeline: five_why, fishbone, is_is_not, fault_tree, pareto or timeline. The quality engineer or the CAPA owner builds them. The conclusion goes into the CAPA itself, as a root cause and a root cause category: man, machine, method, material, measurement, environment, design, supplier or unknown [2].
Actions, and the proof that they worked
The work of a CAPA is a list of rows in qms_capa_action, each with a type, an owner and a due date. The six types are different jobs:
| action_type | What it is for |
|---|---|
| containment | Stop the problem spreading now: hold the lot, sort the stock |
| correction | Fix the nonconformity that already exists |
| corrective | Remove the cause so it does not return |
| preventive | Stop the same kind of problem happening somewhere else |
| training | Teach people the change; writes qms.capa_action.training_required for the training module (M07) |
| document_change | Change a controlled document, linked to a change request |
An owner completes an action and attaches the evidence; a different person, never the owner, verifies it. Before the CAPA reaches implementation it has effectiveness criteria and an effectiveness due date: what will be true, measured how, by when, if the fix worked. After that date the quality engineer records effective or not_effective against the criteria. This is the Check in Plan-Do-Check-Act [5], and it is what separates a CAPA from a to-do list.
Knowledge check
Which of these does the database refuse?
Audits: finding problems first
An audit (qms_audit) is an internal, supplier, customer, regulatory, certification, process, product or layered audit, with a standard reference, a scope, a lead auditor, an auditee and planned dates. Its checklist (qms_audit_item) has one row per question, with the clause reference, a result and the evidence. The results are conform, minor_nc, major_nc, ofi (opportunity for improvement), not_applicable and not_audited.
ISO 9001:2015 clause 9.2 asks that audits are run so that the auditors are objective and impartial [1]. In the module that becomes a rule: an auditor's home site (core_person.home_site_id) must differ from the audit's site_id, and an audit with no site_id, such as a supplier audit, is open to any assigned auditor. An audit cannot close while any checklist item has no result.
Change control: changing safely
A change request (qms_change_control) records what is changing and why: the type (process, equipment, material, supplier, document, software, facility or product), a classification (minor, major or critical), a risk level and an impact assessment kept as JSON, across documents, training, validation and regulatory filings. The work to carry it out is a list of rows in qms_change_task: document, training, validation, regulatory, equipment, supplier, it or other.
The signature is an approver's, with the meaning approved [6]; approving writes qms.change_control.approved for other modules to act on. A change request can also come from a CAPA, when an action of type document_change links to it. The engineering change of a product definition itself belongs to M14; the request here links to it.
You need: Read access to one closed CAPA in your eQMS, a text file, and the quality manager
Choose a CAPA that is closed, preferably about a repeat problem. Look only at its fields; do not copy any names.
Outcome: A one-page gate review of a real CAPA that names the weakest gate, ready to turn into a test in Session 4.
Knowledge check
An audit checklist item is marked major_nc. What happens next in the module?
References
- ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html
- ASQ: What is root cause analysis?. https://asq.org/quality-resources/root-cause-analysis
- ASQ: Fishbone (cause and effect) diagram. https://asq.org/quality-resources/fishbone
- ASQ: Five whys and five whys analysis. https://asq.org/quality-resources/five-whys
- ASQ: The Plan-Do-Check-Act (PDCA) cycle. https://asq.org/quality-resources/pdca-cycle
- 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
Chapter 3 · Ranking risk and managing suppliers
Risk, FMEA and supplier quality
FMEA asks what could go wrong before it does. Supplier quality asks who sends you the things that could go wrong. This chapter covers how a failure mode is rated, why the product of three numbers is no longer enough, and how the approved supplier list, the scorecard and PPAP keep suppliers under control.
20 minRatings 1 to 101,000 combinations5 supplier statuses
By the end of this chapter you can
- Describe an FMEA line and the three ratings that drive its action priority.
- Explain why an RPN alone hides risk, and what the AIAG-VDA action priority does instead.
- Describe the approved supplier list statuses, the scorecard and what PPAP tracks.
FMEA: finding failures on paper
Failure mode and effects analysis lists, step by step, how a design or a process could fail, what that would cause, and what is done about it [2]. In the module an FMEA has a header (qms_fmea: number, type design, process or machinery, the item or process it covers, a revision, the team, and a status of draft, active or superseded) and many lines (qms_fmea_line). The AIAG-VDA FMEA Handbook (2019) describes a seven-step method: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation [6].
Each line names a step or function, a failure mode, its effect, the cause, the prevention controls and the detection controls. Three ratings, each a whole number from 1 to 10, score it: severity of the effect, occurrence of the cause, and detection of the failure before it reaches the customer. The line may mark a special characteristic: none, cc (critical) or sc (significant), which the control plan (M09) follows. A recommended action gets an owner and a due date, and after it is done the line records the revised severity, occurrence and detection.
Action priority, not RPN alone
For many years lines were ranked by the risk priority number (RPN), the product severity × occurrence × detection. Two very different lines can have the same product.
The AIAG-VDA handbook replaces ranking by RPN alone with an action priority of high, medium or low, read from a table of the three ratings [6]. In the module a function, qms_action_priority(s, o, d), holds that table, and a trigger on qms_fmea_line always sets action_priority from it, so a typed value is never trusted.
Risk methods differ by industry. ISO 14971:2019 covers risk management for medical devices [3], and ICH Q9(R1) quality risk management applies to pharmaceuticals [4]. The module's tables keep the names qms_fmea and qms_fmea_line, because the CivOps automated process FMEA and control plan generation build on them.
You need: One process step from your own plant, a text file, and the person who runs that step
Pick one step that has caused a problem in the last year. You will not need the handbook's table for this exercise; the aim is the ratings and the RPN comparison.
Outcome: Three rated FMEA lines with ratings agreed by the person who runs the step, and a note on whether RPN alone would have ranked them correctly.
Knowledge check
Why is ranking FMEA lines by RPN alone a pitfall?
Supplier quality
Suppliers are managed on the approved supplier list (qms_approved_supplier): a supplier, the item class it is approved for, and a status of pending, approved, conditional, probation or disqualified, with the approval date, the date requalification is due, its certifications and a risk rating of low, medium or high. A supplier is always a row in core_party, the shared list of suppliers and customers.
A scorecard (qms_supplier_scorecard) holds the period, ppm (defective parts per million), on-time percentage, the SCAR count, responsiveness, a score and a grade of a, b, c or d. The numbers typed in, ppm and on-time percentage, come from the business's receiving records, with the source noted. A SCAR is a quality event of type scar with the supplier_party_id set, so it appears in every event count as well as on the scorecard.
For automotive suppliers, IATF 16949 with the AIAG Core Tools asks for APQP, PPAP, FMEA, MSA and SPC [1][5]. The production part approval process (PPAP) is tracked in qms_ppap_submission: the supplier, the part, the PPAP level (a whole number), the elements as JSON (the module does not fix their list), and a status of requested, submitted, approved, interim or rejected, with the dates submitted and decided.
Knowledge check
How is scar_count on a supplier scorecard set?
References
- AIAG: Quality Core Tools (APQP, CP, PPAP, FMEA, MSA, SPC). https://www.aiag.org/expertise-areas/quality/quality-core-tools
- ASQ: Failure mode and effects analysis (FMEA). https://asq.org/quality-resources/fmea
- ISO 14971:2019, Medical devices: application of risk management. https://www.iso.org/standard/72704.html
- ICH quality guidelines, including Q9(R1) and Q10. https://www.ich.org/page/quality-guidelines
- IATF Global Oversight: IATF 16949. https://www.iatfglobaloversight.org/
- AIAG: AIAG & VDA FMEA Handbook (product FMEAAV-1). https://www.aiag.org/training-and-resources/manuals/details/FMEAAV-1
Chapter 4 · Building it and replacing the old tool
Tables, roles, KPIs and cutover
Everything so far becomes eighteen tables, five roles, a short list of screens and six numbers. This chapter is the reference you build from in Session 2: every table and column, who does what, how the numbers are counted, the three checks that define done, and how the old history comes in.
30 min18 tables5 roles6 KPIs
By the end of this chapter you can
- Name the eighteen qms_ tables and read their columns, types and required flags.
- Say what the five roles and four machine accounts do, and why the rights must cover the whole module.
- Define each KPI and hand-count the seeded data to check a dashboard.
- State the three checks that define done and the rule for importing history from the old tool.
Eighteen tables on the shared spine
Every table starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. Foreign keys point only at core_ tables and at each other. The table below lists every column the module adds. It is what your agent builds from in Session 2.
Types are as in the specification: text, int, num (a decimal number), bool, ts (a timestamp with time zone), date, uuid, json (jsonb in Postgres), qty (a quantity) and money. An arrow means a foreign key to that table. req means required (not null), and a list after a colon is the set of allowed values, enforced by a check constraint.
| Table | Holds | Columns: type, req = required |
|---|---|---|
| qms_quality_event | Supertype record for all quality events | event_no text req, unique per tenant; event_type text req: ncr, deviation, complaint, audit_finding, scar, observation, oos; title text req; description text; severity text req: critical, major, minor, observation; status text req: new, triage, investigation, disposition, capa_pending, closed, cancelled; site_id → core_site; occurred_at ts; reported_by → core_person; owner_id → core_person; item_id → core_item; lot_id → core_lot; equipment_id → core_equipment; supplier_party_id → core_party; customer_party_id → core_party; source_type text; source_id uuid; due_at ts; closed_at ts; closure_signature_id → core_e_signature |
| qms_defect_code | Defect taxonomy | code text req, unique per tenant; name text req; category text; parent_id → qms_defect_code |
| qms_ncr_detail | Nonconformance detail and MRB disposition | quality_event_id → qms_quality_event req, unique; qty_affected qty; uom_id → core_uom; defect_code_id → qms_defect_code; containment text; disposition text req: pending, use_as_is, rework, repair, scrap, return_to_vendor, regrade; mrb_decided_at ts; mrb_signature_id → core_e_signature; copq_cost money |
| qms_complaint_detail | Complaint-specific data | quality_event_id → qms_quality_event req, unique; channel text req: email, phone, portal, sales, field_service, regulator; contact_ref uuid; rma_no text; product_returned bool; reportable bool; reportability_rationale text; response_due_at ts; responded_at ts |
| qms_deviation_detail | Deviation-specific data | quality_event_id → qms_quality_event req, unique; planned bool req; impact_assessment text; batches_affected json; product_impact text: none, potential, confirmed |
| qms_hold | Quality hold on a lot, order, equipment or supplier | hold_no text req, unique per tenant; target_type text req: lot, production_order, equipment, supplier, item, location; target_id uuid req; reason text req; quality_event_id → qms_quality_event; placed_by → core_person req; placed_at ts req; released_by → core_person; released_at ts; release_signature_id → core_e_signature; status text req: active, released, converted_to_scrap |
| qms_capa | Corrective and preventive action record | capa_no text req, unique per tenant; origin_event_id → qms_quality_event; title text req; problem_statement text req; method text req: eight_d, five_why, a3, dmaic, other; containment text; root_cause text; root_cause_category text: man, machine, method, material, measurement, environment, design, supplier, unknown; status text req: open, investigation, action_plan, implementation, effectiveness_check, closed, cancelled; owner_id → core_person req; due_at ts; effectiveness_criteria text; effectiveness_due_at ts; effectiveness_result text: pending, effective, not_effective; closed_at ts; closure_signature_id → core_e_signature |
| qms_capa_action | Action within a CAPA | capa_id → qms_capa req; action_type text req: containment, correction, corrective, preventive, training, document_change; description text req; owner_id → core_person; due_at ts; completed_at ts; verified_by → core_person; verified_at ts; linked_type text; linked_id uuid |
| qms_rca_artifact | Root-cause tool content (fishbone, 5-Why, is/is-not, fault tree) | capa_id → qms_capa req; tool text req: fishbone, five_why, is_is_not, fault_tree, pareto, timeline; content json req; author_id → core_person |
| qms_audit | Audit instance | audit_no text req, unique per tenant; audit_type text req: internal, supplier, customer, regulatory, certification, process, product, layered; standard_ref text; scope text; lead_auditor_id → core_person; auditee_party_id → core_party; site_id → core_site; planned_start date; planned_end date; status text req: planned, in_progress, reporting, closed, cancelled; report_attachment_id → core_attachment |
| qms_audit_item | Checklist item and result | audit_id → qms_audit req; clause_ref text; question text req; result text: conform, minor_nc, major_nc, ofi, not_applicable, not_audited; evidence text; finding_event_id → qms_quality_event |
| qms_change_control | Change request with impact assessment | cc_no text req, unique per tenant; title text req; change_type text req: process, equipment, material, supplier, document, software, facility, product; classification text req: minor, major, critical; reason text req; impact_assessment json; risk_level text: low, medium, high; status text req: draft, assessment, approval, implementation, effectiveness_review, closed, rejected; owner_id → core_person req; implementation_due date; approved_signature_id → core_e_signature |
| qms_change_task | Implementation task of a change | change_control_id → qms_change_control req; task_type text req: document, training, validation, regulatory, equipment, supplier, it, other; description text req; owner_id → core_person; due_at ts; completed_at ts |
| qms_fmea | FMEA header (design or process) | fmea_no text req, unique per tenant; fmea_type text req: design, process, machinery; item_id → core_item; process_ref text; revision text req; team json; status text req: draft, active, superseded |
| qms_fmea_line | Failure mode line with S/O/D and AIAG-VDA action priority | fmea_id → qms_fmea req; step_function text req; failure_mode text req; failure_effect text; severity int req; failure_cause text; occurrence int req; prevention_controls text; detection_controls text; detection int req; action_priority text req: high, medium, low; special_characteristic text: none, cc, sc; recommended_action text; owner_id → core_person; due_at ts; revised_severity int; revised_occurrence int; revised_detection int |
| qms_approved_supplier | Approved supplier list entry by commodity | supplier_party_id → core_party req; item_class_id → core_item_class; status text req: pending, approved, conditional, probation, disqualified; approved_at date; requalify_due date; certifications json; risk_rating text: low, medium, high |
| qms_supplier_scorecard | Periodic supplier performance | supplier_party_id → core_party req; period_start date req; period_end date req; ppm num; on_time_pct num; scar_count int; responsiveness num; score num; grade text: a, b, c, d |
| qms_ppap_submission | PPAP status per part and supplier | supplier_party_id → core_party req; item_id → core_item req; level int req; elements json req; status text req: requested, submitted, approved, interim, rejected; submitted_at date; decided_at date |
Look at the rules that follow from the list. event_no, hold_no, capa_no, audit_no, cc_no and fmea_no are each unique per tenant, issued from the spine's number sequences and never counted by hand. The ratings on qms_fmea_line and the three revised ratings are whole numbers from 1 to 10. A detail table's quality_event_id is required and unique. Money and quantities are typed columns, and JSON is used only where the shape varies: root cause artifacts, impact assessments, teams, certifications, PPAP elements.
Five roles, four machine accounts
Roles are jobs, not names, and each maps to a row in the spine's core_job_role. The Role and Exposure Matrix of Session 3 gives each one the rights its job needs and nothing else. Nobody gets delete: a correction is a new row or a cancelled status.
| Surface | Screens | Who opens them |
|---|---|---|
| Operator, on the phone | /quality/report, /quality/my-actions | Reporter and quality engineer; CAPA owner |
| Supervisor | /quality/events, /quality/events/[id], /quality/capa, /quality/capa/[id], /quality/audits/[id], /quality/fmea, /quality/changes, /quality/suppliers | Quality engineer; CAPA owner for CAPA; auditor for audits |
| Manager | /quality/approvals, /quality/kpis | Approver; the quality engineer may open the KPIs |
Other modules talk to this one through events. It publishes qms.event.created, qms.hold.placed, qms.hold.released, qms.capa.closed, qms.change_control.approved and qms.capa_action.training_required. It consumes frm.response.failed, spc.violation.detected, lims.result.oos, mes.parameter.out_of_spec, cmms.calibration.out_of_tolerance and svc.ticket.complaint.
Knowledge check
Why must the rights of Sessions 4 to 6 be checked against the matrix in Session 3?
Six numbers
| KPI | Definition |
|---|---|
| CAPA on-time closure | CAPAs closed by the due date ÷ CAPAs due |
| CAPA effectiveness rate | Effective ÷ verified CAPAs |
| Cost of poor quality | Scrap + rework + returns + concessions cost per period |
| Internal and customer ppm | Defective parts per million |
| Repeat event rate | Events matching a previously closed root cause ÷ events |
| Supplier ppm and on-time delivery | From the supplier scorecards |
Management review under ISO 9001:2015 clause 9.3 is where numbers like these are looked at [4], and a dashboard is only trusted when it matches a count made by hand. Session 2 seeds a small, invented quarter: eight events, six CAPAs, two holds and one audit. In Session 4 you count it by hand, then build the dashboard on queries over the typed tables, and it must match exactly. If it does not, fix the query, not the count.
Three checks that define done
- A held lot cannot be consumed in MES or shipped in WMS (a cross-module test).
- A CAPA cannot close without an effectiveness result.
- The action priority computed from severity, occurrence and detection matches the AIAG-VDA table on test vectors read independently from the handbook.
Three compliance rules sit beside them. Holds are enforced at the database and API level in every module that can move or consume material. Closure and MRB disposition require electronic signatures [1]. A complaint's reportability decision must record its rationale. Analytics and AI suggestions, such as triage or CAPA drafts, are drafts only: a person approves each one.
Cutover: the old history comes in
Export the open and closed events, CAPAs and audits with their attachments from the old eQMS. Open work and active holds come in live; closed records come in as read-only history, with the original signatures kept as attached evidence, not as new signatures.
The old tool's bill is a figure from its invoice, never an estimate. Read the vendor's cancellation terms from your own account page (notice period, renewal date, export window) and take the full export before the last day. Further reading on what buyers weigh when choosing or replacing a QMS tool is in [2] and [3].
You need: A report or export from your eQMS (counts only), a spreadsheet, and the quality manager
Use counts, not records: no names, no customers, no free text. This is the count your dashboard will have to match.
Outcome: A confirmed hand count of one quarter, with the report named, which a new dashboard must match exactly.
Knowledge check
Which is the definition of CAPA on-time closure?
References
- 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
- Rajesh Kumar: top 10 QMS buyer criteria. https://www.rajeshkumar.xyz/blog/quality-management-systems-qms/
- SoftwareConnect: TrackWise eQMS. https://softwareconnect.com/reviews/trackwise/
- ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html
Chapter 5 · 13 questions · 80% passes
Final assessment
Thirteen questions across the element. Score 80% (11 of 13) to pass. Your LMS records your score and each answer; you can review the chapters and try again.
15 min13 questions≈ 15 minutesRetake allowed
Your result
CivOps AI Academy
Quality Management: Events, CAPA, Audits, Change, Risk and Supplier Quality on One Record Model
Element M08 complete · Learner
Your LMS records this completion. For the CivOps Foundation certificate, finish the Foundation Course at https://civops.io/learn.