Intended Use and User Requirements — QMS Nordic
Template — QMS Nordic T2. This is the document an auditor turns to first, and the one most often missing.
It is pre-written, and that is deliberate. Section 3 states an intended use and requirements covering how QMS Nordic is normally used. Your job is not to write it from blank — it is to confirm each line reflects how you actually use the platform, correct anything that differs, and add anything you rely on that we have not listed.
The rule that matters: anything you rely on which is not covered here becomes your own validation deliverable. The confirmation is the point — ticking a line is a statement that you checked it, and an auditor will ask.
Effort: half a day, mostly reading. Longer if your configuration is unusual.
| Document | [DOC-XXX] Intended use and user requirements — QMS Nordic |
| Software | QMS Nordic v1.5.0 |
| Register ID | [SW-001] |
| Risk category | [High] (see your T1 SOP §5.2 — an eQMS holding controlled records is normally High) |
| Owner | [Quality Manager] |
| Date | [date] |
1. Purpose
To state what [COMPANY] uses QMS Nordic for, in our processes and our configuration, and the requirements it must meet — the basis against which it is validated and re-validated.
2. How to complete this
For every requirement in §3:
| Mark | Meaning |
|---|---|
| ✅ Confirmed | We use this, and the description matches how we use it. |
| ✏️ Amended | We use this, but differently — the difference is written in the Notes column. |
| ➖ Not used | We do not use this function. No validation needed; say so and move on. |
| ➕ Added | Something we rely on that is not listed. Add a row. This is your validation deliverable. |
An honest ➖ is worth more than a reflexive ✅. Marking something confirmed that you do not actually use creates a testing obligation you do not need; and if an auditor probes a workflow you claimed and cannot demonstrate, the credibility of every other line drops with it.
3. Intended use
Proposed statement — review and adopt, amend, or replace.
[COMPANY] uses QMS Nordic as its electronic quality management system: the authoritative system of record for controlled documents, and for the quality processes we have enabled. It is used by [N] users across [sites/functions] in support of [EU MDR / FDA QMSR / MDSAP / UKCA] compliance.
Records created in QMS Nordic are [the authoritative record / a copy of a record held elsewhere] — delete as applicable; this single choice changes the risk category, so state it explicitly.
We do not use QMS Nordic for [design outputs / device software / clinical data / …] — list what you deliberately keep outside it.
Confirmation: ☐ Adopted as written ☐ Amended (see notes) ☐ Replaced
4. User requirements
4.1 Records and document control
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-DOC-01 | Controlled documents are created, reviewed and approved in the system, with a defined lifecycle | ☐✅ ☐✏️ ☐➖ | |
| URS-DOC-02 | Each document carries a unique identifier and a version; superseded versions remain retrievable | ☐✅ ☐✏️ ☐➖ | |
| URS-DOC-03 | Only approved, current versions are presented to users as effective | ☐✅ ☐✏️ ☐➖ | |
| URS-DOC-04 | Obsolete documents are prevented from unintended use | ☐✅ ☐✏️ ☐➖ | |
| URS-DOC-05 | Periodic review dates are tracked and surfaced before they lapse | ☐✅ ☐✏️ ☐➖ |
4.2 Record integrity and audit trail
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-AUD-01 | Every create, change and delete of a quality record is recorded with actor, timestamp and previous value | ☐✅ ☐✏️ ☐➖ | |
| URS-AUD-02 | The audit trail cannot be altered or deleted by users, including administrators | ☐✅ ☐✏️ ☐➖ | |
| URS-AUD-03 | Alteration of an audit record is detectable | ☐✅ ☐✏️ ☐➖ | |
| URS-AUD-04 | The audit trail is readable and exportable for review | ☐✅ ☐✏️ ☐➖ |
4.3 Electronic signature (if you rely on e-signature — otherwise mark ➖ throughout)
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-SIG-01 | Signing requires the signer to re-authenticate at the moment of signing | ☐✅ ☐✏️ ☐➖ | |
| URS-SIG-02 | The signature records signer, date, time and the meaning of the signature | ☐✅ ☐✏️ ☐➖ | |
| URS-SIG-03 | A signature is bound to the specific record signed and cannot be transferred to another | ☐✅ ☐✏️ ☐➖ | |
| URS-SIG-04 | Signed records cannot be modified without invalidating the signature | ☐✅ ☐✏️ ☐➖ |
4.4 Access control and separation
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-ACC-01 | Access requires authentication; permissions are assigned by role | ☐✅ ☐✏️ ☐➖ | |
| URS-ACC-02 | Users see only records belonging to our organisation | ☐✅ ☐✏️ ☐➖ | |
| URS-ACC-03 | Separation of duties can be enforced where our processes require it | ☐✅ ☐✏️ ☐➖ | |
| URS-ACC-04 | Access is removed promptly when a user leaves | ☐✅ ☐✏️ ☐➖ | Your joiner/leaver process — usually your gap, not ours |
4.5 Availability and retention
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-RET-01 | Records remain legible and retrievable for our retention period | ☐✅ ☐✏️ ☐➖ | State your period: [—] |
| URS-RET-02 | Records can be exported in a usable format without vendor assistance | ☐✅ ☐✏️ ☐➖ | |
| URS-RET-03 | Data is backed up and restorable | ☐✅ ☐✏️ ☐➖ |
We hold no automated evidence for any of these three, and we have never rehearsed a restore of production. Managed point-in-time recovery is in place; a demonstrated recovery time is not. Do not accept a backup policy as evidence of a restore — from us or from any vendor.
4.6 AI-assisted drafting (mark ➖ throughout if you do not use it)
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-AI-01 | AI-generated content is identifiable as such, with recorded provenance | ☐✅ ☐✏️ ☐➖ | |
| URS-AI-02 | No AI-generated document becomes effective without human review and approval | ☐✅ ☐✏️ ☐➖ | |
| URS-AI-03 | An incomplete generation is flagged rather than presented as complete | ☐✅ ☐✏️ ☐➖ | |
| URS-AI-04 | A failure of the AI provider does not produce a document | ☐✅ ☐✏️ ☐➖ |
Read URS-AI-02 carefully. The AI does not produce validated output and is not validated as such — model output is not deterministic. The control is your review. If your process lets an AI draft reach effective status without a human approving it, that is a finding waiting to happen, and no vendor evidence will help you.
4.7 Platform change control
| ID | Requirement | Status | Notes |
|---|---|---|---|
| URS-CHG-01 | Changes to the platform are recorded, reviewed and traceable to a released version | ☐✅ ☐✏️ ☐➖ | |
| URS-CHG-02 | The recorded change history reproduces the validated system | ☐✅ ☐✏️ ☐➖ |
4.8 Modules in use
Tick only what you actually use. Each ticked module is something you should exercise in your testing (T4); each unticked one is out of scope for your validation.
- ☐Document control ☐ CAPA ☐ Complaints ☐ Nonconformance ☐ Audits
- ☐Management review ☐ Training ☐ Risk management ☐ Supplier management
- ☐Equipment / calibration ☐ Change control ☐ Post-market surveillance
- ☐Clinical evaluation ☐ Technical documentation ☐ Production / batch records
- ☐Stock and procurement ☐ Other: [—]
4.9 Added requirements
Anything you rely on that is not listed above. These are yours to validate.
| ID | Requirement | Why it matters to us |
|---|---|---|
| URS-ADD-01 | ||
| URS-ADD-02 |
5. Assumptions and constraints
- Supported browsers: [current versions of Chrome / Edge / Firefox / Safari]
- Identity provider: [—] (configured by you; not covered by our validation)
- Data residency: EU (Frankfurt)
- Integrations: [—] (each one is your validation deliverable)
6. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Prepared by | |||
| Reviewed by | |||
| Approved by ([Quality Manager]) |
QMSN-T2 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/t2-intended-use. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.