What IEC 62304's safety classification decides before a line of code is written

A team building a Class C dosing-calculation algorithm and a team building a Class A settings-preferences screen can run the identical development process IEC 62304 describes and still owe entirely different files at the end of it, because the standard doesn't scale its documentation requirements to a project's size, a company's habits, or how much time is left before launch. It scales them to a single determination made once, early, at Clause 4.3: the software safety classification, decided in terms of the harm the software could cause or contribute to if it fails. Get that classification wrong on the low side and a file quietly under-documents software that's actually driving a hazardous situation. Get it wrong on the high side and a team spends effort a lower-risk component never needed. Either way, the mistake happens before the first requirement is written, not after, in some later document review.

A question about harm, not about complexity

Clause 4.3 sorts software into three classes by the severity of harm a hazardous situation it contributes to could cause: Class A, where no injury or damage to health is possible; Class B, where non-serious injury is possible; and Class C, where death or serious injury is possible. The sort runs on possible harm, not on how large, novel, or technically demanding the software is — a small utility computing a drug dose can sit at Class C because of what a wrong answer does downstream, while a sprawling but functionally isolated logging module can sit at Class A because nothing it does or fails to do ever reaches the patient. The standard does allow a software item to carry a lower class than its parent system, but only where the manufacturer can verify adequate segregation between that item and the higher-class components around it — a determination that has to be demonstrated, not asserted in a spreadsheet cell.

What each class actually buys the file

Class A software only needs software requirements (Clause 5.2) and software release (5.8) documented as freestanding records. Class B adds software architecture (5.3) and the verification activities at 5.5 through 5.7. Class C adds detailed design (5.4) on top of all of it. A genuine Class A determination isn't a shortcut around rigor — it's a real, standard-sanctioned reduction in required documentation, available precisely because the classification itself, done honestly, says the harm ceiling is low.

The clauses that don't scale down with it

That scaling applies only to Clause 5's development-process documentation. Clause 7's software risk management, tied back into ISO 14971, Clause 8's configuration management, and Clause 9's problem resolution apply at every safety class without reduction. A Class A file that skips risk management on the reasoning that “it's only Class A” has confused the one clause the classification is allowed to scale with the ones it was never meant to touch.

The classification isn't fixed at first guess

Clause 4.3 isn't a form filled out once at kickoff and filed away. A change to intended use, a newly identified hazardous situation, or a change in the risk controls a hazard depends on can move a software item's classification, almost always upward, since a downward move needs new segregation evidence to support it. A classification record with no trigger tied to the device's own change control, or to the risk management file's own per-hazard traceability chain, has the same gap a 510(k) change record has when it never revisits whether a later design change moves the answer it settled at launch.

Not the same question the QMS software-validation clauses ask

ISO 13485's software-validation clauses ask whether software an organization uses to run its own operations — the QMS platform, production-line control software, measurement-equipment firmware — does what it's supposed to do. IEC 62304 asks a different question, about software that is the device or is embedded in it: not whether it works as intended, but what its own defects could do to a patient if it doesn't. A single product line can owe both files at once — a document-control platform validated under Clause 4.1.6, and a glucose-monitor algorithm classified and documented under IEC 62304 — and treating the two as one question is how a validation matrix ends up with the wrong shape of evidence sitting next to the wrong clause.

A software safety classification worksheet built around Clause 4.3's harm-based test, with the class-to-documentation matrix and a defined reclassification trigger, is previewed in the launch catalog. If your team's segregation argument for downgrading a component's class works differently, the shelf takes that correction directly.