Home Features Standards conformity
Clause by clause, against the standards you actually claim
The Planning view answers a reviewer directly: for this clause, what do you hold and where is it? Nothing is ever reported as a gap.
Four standards, one view
- IEC 62304:2006+A1:2015 — software life cycle processes, clause 4 through clause 9. Still the edition in force; Edition 2 is in ballot.
- FDA — Content of Premarket Submissions for Device Software Functions (June 2023).
- FDA — Cybersecurity in Medical Devices: Quality Management System Considerations (3 February 2026), which supersedes the June 2025 edition and aligns with the QMSR.
- FDA — Off-The-Shelf Software Use in Medical Devices (August 2023).
Design controls are cited at ISO 13485 §7.3, which the FDA’s Quality Management System Regulation has incorporated by reference into 21 CFR Part 820 since 2 February 2026.
Status is derived, not asserted
Each clause reads its status from the loaded documents. “12 software units, 9 stating acceptance criteria” is counted at the moment you look, so it cannot describe evidence that has since been deleted.
Nothing is a gap
A clause SpecPad does not hold is not a hole in your evidence — it is evidence another system holds. Development planning, maintenance and problem resolution live in a quality system and an issue tracker, and the view says so, naming the kind of system rather than a document number that would go stale.
The same page states what is deliberately not held here — no SBOM, no probability on a software risk, no requirement-to-architecture matrix, no design validation — each with its reason, so a reviewer is never left inferring whether an absence was a decision.
Requirements say what kind they are
IEC 62304 §5.2.2 lists twelve content categories, and A1:2015 adds a note saying plainly that they can overlap — so a requirement carries as many as apply. The value is the sweep: a category with nothing under it is a question worth answering once, not an omission found at review.
| Category | What it covers | |
|---|---|---|
a) | Functional | Functional and capability requirements |
b) | Inputs/outputs | Software system inputs and outputs |
c) | Interfaces | Interfaces between the software system and other systems |
d) | Alarms | Software-driven alarms, warnings and operator messages |
e) | Security | Security requirements, including system security and malware protection |
f) | User interface | User interface requirements implemented by software (A1:2015) |
g) | Data | Data definition and database requirements |
h) | Installation | Installation and acceptance at the operation and maintenance site |
i) | Operation | Requirements related to methods of operation and maintenance |
j) | IT-network | Requirements related to IT-network aspects: networked alarms, protocols, and unavailability of network services (A1:2015) |
k) | User maintenance | User maintenance requirements |
l) | Regulatory | Regulatory requirements |
Methodologies, stated once
Not standards conformed to — techniques chosen: arc42 and C4, IEEE 1016 design views, ISO 14971 through clause 7, the MITRE/MDIC threat modelling playbook, AAMI SW96 exploitability, Diátaxis for the authoring guides. Each with the reason it was picked. A reviewer reads it to know what evidence to expect; an engineer joining reads it to know how to work.