Performance Qualification — QMS Nordic platform

Performance Qualification — QMS Nordic platform
Document ID	QMSN-PQ-001
Applies to	QMS Nordic v1.5.0
Part of	The software validation pack
Executed by	You, in your own tenant, with your own people and data
When	Once on activation; on any release the release record classes as Major for a module you use; and at your revalidation interval

1. What this is

The Installation Qualification establishes that your tenant is configured; the Operational Qualification establishes that the 26 platform requirements hold, with our automated evidence beside each. Neither says whether the platform does your work correctly — whether your CAPA procedure, run in this software, by your people, produces a closed CAPA your auditor accepts. That is performance qualification, and it can only be done by you.

This document is organised by module, not by requirement. ISO 13485 §4.1.6 asks you to validate software for its intended use; your intended use is the modules you rely on. Run only the sections for modules you use. A manufacturer who keeps documents and training here but runs CAPA elsewhere runs §3 and §7 and ignores the rest, and says so in T5.

Each section names the module evidence we hold (QMSN-MEA-001, by section id), so you can see where our testing ends and yours begins, and keep your own steps to what only you can confirm. Record results in template T4; conclude in T5.

2. Before you start

Your tenant passes the IQ checklist (QMSN-IQ-001).
Your users have the roles they will really hold. Several steps below need two people with different roles; do not run them as one administrator.
Use test records with an obvious prefix (PQ-) so they can be identified and, if you wish, retired afterwards. Nothing you create here is deleted by the platform.
Note the platform version from the pack page before you begin, and record it in T4.

3. Documents and signatures

Applies to every tenant. Our evidence: this module is the requirement register itself — see the OQ, URS-DOC-* and URS-SIG-*.

3. Documents and signatures
Step	Do	Expected
3.1	As an author, create `PQ-SOP-01` from your own SOP template and submit it for review.	The document is in review; the author cannot approve it.
3.2	As a second person with approval rights, approve and sign.	Re-authentication is demanded at signing; the signature shows name, time and meaning.
3.3	Make it effective; then, as any user, open the document list.	`PQ-SOP-01` is offered as effective; no draft is.
3.4	As the author, edit the effective text.	A new draft version is created; the signed version is untouched and still signed.
3.5	Open the document's audit trail and export it.	Every step above is present with actor and time; the export opens outside the platform.

4. Corrective and preventive action

Applies if you run CAPA here. Our evidence: M-CAPA.

4. Corrective and preventive action
Step	Do	Expected
4.1	Open `PQ-CAPA-01` from a source you actually use (an NCR, a complaint, an audit finding).	The case has a number and is open; the source is linked.
4.2	Attempt to advance to implementation with only a corrective action written.	Refused until a preventive action is also written.
4.3	Write both, advance, and attempt to close.	Refused: effectiveness not verified, with the clause named.
4.4	Record an effectiveness check as your procedure requires; close.	Closed, by the person who closed it, with the trail showing each transition.
4.5	Yours alone: review the closed case against your CAPA SOP.	Root cause, actions and effectiveness criteria meet your procedure — the platform cannot judge this.

5. Complaints and vigilance

Applies if you handle complaints here. Our evidence: M-CMP.

5. Complaints and vigilance
Step	Do	Expected
5.1	Log `PQ-CMP-01` with an awareness date three days ago and flag it serious under the EU MDR.	The dashboard shows the Article 87 deadline counting from the awareness date, not from today.
5.2	Attempt to close it.	Refused: report outstanding.
5.3	Record the report with your competent-authority reference; close.	Closed; the reference and the report date are on the record.
5.4	Log `PQ-CMP-02` unflagged and close it.	Closes without a report.
5.5	Yours alone: confirm the flags you set in 5.1 match your vigilance procedure's decision tree.	The reportability decision is yours; the platform computed only the deadline.

6. Management review

Applies if you record management review here. Our evidence: M-MR.

6. Management review
Step	Do	Expected
6.1	As a quality administrator, plan `PQ-MR-01`; as an RA user, attempt the same.	Planned; the RA user is refused.
6.2	Conduct the review with the inputs the platform assembles.	The §5.6.2 inputs — audits, complaints, CAPA, suppliers — are drawn from your records.
6.3	Attempt to close without outputs.	Refused: outputs required per §5.6.3.
6.4	Record improvement, resource and product outputs; close; attempt an edit.	Closed and frozen.
6.5	Yours alone: compare the assembled inputs with your own agenda.	Anything your procedure requires that the platform did not assemble is added by you.

7. Training and competence

Applies if you keep training records here. Our evidence: M-TRN.

7. Training and competence
Step	Do	Expected
7.1	Assign `PQ-SOP-01` as training to an operator.	The operator sees the assignment; it is not complete.
7.2	As a colleague of the same role, attempt to complete it for them.	Refused.
7.3	As the operator, complete it; as the operator, attempt to verify it.	Completed; self-verification refused.
7.4	As a quality administrator, verify.	Verified, with verifier and time.
7.5	Yours alone: decide how competence is assessed before verification.	The platform records that a different person verified; the assessment is your procedure.

8. Supplier control

Applies if you keep the approved supplier list here. Our evidence: M-SUP.

8. Supplier control
Step	Do	Expected
8.1	Create `PQ-SUP-01` and attempt a second supplier with the same code.	The second is refused.
8.2	Move it to approved with your evaluation notes; then to conditional.	Each change is on the trail with the previous status; approval carries a date.
8.3	As an auditor, attempt to change the status.	Refused.
8.4	Yours alone: attach or reference the evaluation behind the approval.	Your criteria, audit and agreement are yours to hold; the platform records the outcome.

9. Equipment and calibration

Applies if you keep the equipment register here. Our evidence: M-EQP.

9. Equipment and calibration
Step	Do	Expected
9.1	Register `PQ-EQ-01`; attempt a duplicate asset code.	Refused.
9.2	Record a calibration certificate with a due date one year out.	The equipment's next-due date moves to it.
9.3	Record one with a due date before the performed date.	Refused.
9.4	Take the equipment out of service with a reason.	Status and reason on the trail with the previous state.
9.5	Yours alone: confirm the certificate's traceability to national standards.	The platform holds the document; the traceability is your check.

10. Software lifecycle

Applies if you manage device software here. Our evidence: M-SW.

10. Software lifecycle
Step	Do	Expected
10.1	As an engineer, report `PQ-SWP-01` against a software item.	Numbered and open.
10.2	Attempt to close it.	Refused: not verified.
10.3	Resolve with a root cause and a resolution; as the engineer, attempt to close.	Verified; closure refused for lack of approval rights.
10.4	As a quality administrator, close.	Closed; the trail shows the path.
10.5	Yours alone: the development process (§5–§8), safety classification and SOUP evaluation.	Not covered by our evidence; validate against your own software procedure.

11. Usability and performance evaluation files

Applies if you keep IEC 62366-1 usability files or IVDR performance evaluation reports here. Our evidence: M-USE, M-PE.

11. Usability and performance evaluation files
Step	Do	Expected
11.1	Attempt to approve a usability file before the summative evaluation is marked complete.	Refused.
11.2	Mark it complete without a residual-risk rationale; attempt approval.	Refused until the rationale is recorded and the risk marked acceptable.
11.3	Attempt to approve a performance evaluation report with a pillar left blank.	Refused, naming the pillar.
11.4	Yours alone: the evaluations themselves.	The gates check that they were recorded as done; you check that they were done.

12. Process validation runs

Applies if you record IQ/OQ/PQ of your own processes here. Our evidence: M-VAL.

12. Process validation runs
Step	Do	Expected
12.1	Plan `PQ-VAL-01` for a process; start it; attempt approval before a result is recorded.	Refused.
12.2	Record a result as the executor; attempt to approve as the same person.	Refused: approver must differ.
12.3	Approve as a second person.	Approved; the run is locked.
12.4	Yours alone: the protocol and acceptance criteria.	The platform is the record of the run, not its author.

13. Regulatory submissions

Applies if you assemble technical documentation or 510(k) bundles here. Our evidence: M-SUB.

13. Regulatory submissions
Step	Do	Expected
13.1	Open `PQ-SUB-01`; pin external evidence with neither a title nor a URL.	Refused.
13.2	Pin a document from your tenant to an Annex II section; remove it.	Both actions on the trail; the section's completeness reflects the change.
13.3	Yours alone: whether the dossier is complete.	The gauge counts sections with evidence; you read the evidence.

14. Product classification

Applies if you classify devices here. Our evidence: M-CLS.

14. Product classification
Step	Do	Expected
14.1	Classify `PQ-DEV-01` with your device's real inputs.	The class matches your technical documentation, and the rule fired is cited.
14.2	Change one input that should change the class.	The class changes and the cited rule changes with it.
14.3	Yours alone: the inputs.	The classifier is only as right as what it was told.

15. Product register and market release

Applies if you keep your device register here and use the lifecycle stage. Our evidence: M-PROD.

15. Product register and market release
Step	Do	Expected
15.1	Create `PQ-DEV-02` with the UDI-DI of `PQ-DEV-01`.	Refused, naming the product that already carries it.
15.2	Give `PQ-DEV-02` a GS1 UDI-DI with the last digit wrong.	Refused, stating the check digit expected.
15.3	With no approved Declaration of Conformity on `PQ-DEV-02` or its family, set its stage to ON MARKET and save without a justification.	Refused; the message names the declaration and the justification path.
15.4	Save again with a written justification.	Accepted; the audit trail shows your name, the previous stage and the justification; the page shows who set the stage and when.
15.5	Approve a Declaration of Conformity on `PQ-DEV-01` (or its family) and set it ON MARKET.	Accepted without a justification.
15.6	Yours alone: the declaration.	The platform checks that one is on file, not that it is right.

16. Concluding

A module section passes when every step gives its expected result and every "yours alone" step has been considered and recorded — a written "not applicable, we do not use this module" is a result. A failed step is a deviation: record it in T4, decide with your QA lead whether it blocks use of that module, and tell us. Our contact for validation matters is in the Master Plan.

Conclude in T5 by module, naming the platform version and the date. A T5 that says "PQ passed" without naming the modules run is not evidence of anything in particular.

17. Document history

17. Document history
Version	Date	Change
2.1	2026-09-07	Section 15 added for the product register and market release (M-PROD): UDI-DI uniqueness and check digit, and the Declaration of Conformity gate on ON MARKET, both introduced after the 2026-09-07 end-to-end review. Concluding and history renumbered.
2.0	2026-09-07	Rewritten for QMS Nordic v1.5.0, organised by module rather than by requirement identifier. The previous draft cited a requirement register that no longer exists and was withheld from the pack for that reason; it is superseded entirely.
1.0-draft	2026-04-30	Caelum-era draft, never issued.

QMSN-PQ-001 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/performance-qualification. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.