IEC 62304 is the international standard for medical device software lifecycle processes. It is recognized by the FDA and harmonized under the EU Medical Device Regulation, which means if you build software that is a medical device or software that drives one, this standard defines the process you must be able to prove you followed. The single most consequential decision in the standard is the software safety classification, because it determines how much of the standard actually applies to you.
The standard defines three safety classes, and the boundary between them is the severity of harm that a software failure could cause. Class A: no injury or damage to health is possible from a software failure. Class B: non-serious injury is possible. Class C: death or serious injury is possible. The classification is assigned to the software system as a whole and can also be assigned to individual software items, which is where the real leverage lives.
The classification is not a guess. IEC 62304 (as amended in 2015) requires you to base it on the hazardous situations that could result from a software failure, after considering the external risk control measures outside the software. That last clause matters enormously. If a hardware interlock, a mechanical stop, or an independent monitoring circuit prevents a software failure from ever reaching the patient, the software contribution to that hazard is mitigated, and the software item can be classified lower than the raw hazard severity would suggest. This is how a device with a Class C hazard can contain Class A and Class B software items, provided the architecture keeps the dangerous paths isolated behind non-software controls.
Why the class matters: the amount of required process scales sharply with it. Class A requires the fewest activities — essentially development planning, requirements, and a software release process. Class B adds detailed software design, unit implementation, and integration testing with documented results. Class C adds everything in B plus the most rigorous design detail, documented unit-level verification, and the tightest configuration and problem-resolution controls. Misclassify a Class B item as Class C and you will generate design documentation and unit test evidence that no one needed, burning weeks. Misclassify a Class C item as Class A and you will fail audit — a notified body will find that the software driving a serious-injury hazard was developed without the required design and verification rigor.
The architecture decision that saves the most work is segregation. IEC 62304 explicitly allows you to partition software into items of different classes, provided you can demonstrate that the segregation between them is effective — that a failure in a lower-class item cannot affect a higher-class item. If your entire codebase is one monolith, the whole thing inherits the highest class present, and every module gets Class C treatment. If you architect a small, well-isolated Class C safety kernel and keep the bulk of the application in Class A and Class B items behind a verified boundary, you apply the expensive rigor only where the hazard actually lives. The segregation itself becomes a design element you must document and verify — but it is almost always cheaper than treating everything as Class C.
Classification is not a one-time event. IEC 62304 requires you to establish the class early, in the software development plan, but you must revisit it whenever the risk analysis changes. Adding a feature that touches a safety-relevant path, discovering a new hazardous situation during design, or changing a risk control measure can all move an item up in class — and moving up means the additional process activities now apply retroactively to that item. Programs that lock the classification at project start and never revisit it are the ones that discover, during a pre-submission review, that a feature added in month eight should have been Class C all along.
The classification drives the deliverables the FDA and notified bodies expect. The FDA guidance on premarket software documentation ties the level of documentation to the risk the software poses, which maps closely to the 62304 class in practice. A Class C item needs a documented software architecture, detailed design down to the software unit, unit-level verification with recorded results, integration and system test evidence, and a complete traceability chain from software requirements through design to verification. A Class A item needs far less. Knowing the class tells you exactly which deliverables the auditor will ask to see.
Traceability is the connective tissue the standard demands regardless of class, and it gets stricter as class rises. You must be able to trace from the system requirements to the software requirements, from software requirements to the software architecture and design, from design to the code, and from every software requirement to the verification that proves it is met. For Class C, this chain must be complete and auditable down to the unit. When a requirement changes, everything downstream — design, code, and verification — is potentially affected, and the standard expects you to demonstrate you assessed that impact. Maintaining this by hand across a changing codebase is where most teams lose control.
The software problem resolution process is another activity whose rigor scales with class. Every anomaly must be recorded, evaluated for its safety relevance, and dispositioned. For Class C, you must show that problems affecting safety were analyzed, that the change to fix them was verified, and that you assessed whether the fix introduced new problems. A pile of GitHub issues is not a 62304 problem resolution record. The auditor wants to see that each safety-relevant anomaly was formally evaluated against the risk analysis and closed with verified evidence.
Common classification pitfalls: defaulting the whole system to Class C out of caution and then drowning in unnecessary documentation; classifying by device risk rather than by software failure contribution, ignoring the external risk controls that legitimately lower the software class; failing to document the rationale for a classification (the auditor wants to see why, not just what); and treating segregation as a claim rather than a verified design element. The rationale and the segregation evidence are what turn a lower classification from an assertion into a defensible position.
A practical workflow: start from your ISO 14971 risk analysis, identify every hazardous situation software could contribute to, and for each one determine the severity of harm after external risk controls. Assign the software item its class from the worst-case surviving severity. Architect deliberately to segregate the highest-class items into the smallest possible footprint. Document the classification rationale for each item. Then apply the 62304 process activities per item at the level its class requires, and maintain the traceability and problem-resolution records the class demands. Revisit the whole thing every time the risk picture changes.
Hitt Hosting SE's Medical Device pack is built around this workflow. Software items carry their IEC 62304 safety class as a first-class attribute, with the classification rationale and the ISO 14971 hazard link recorded alongside. The requirements-to-design-to-verification traceability chain the standard demands is maintained automatically, so when a software requirement changes, the affected design elements and verification activities are flagged for reassessment. Anomalies flow through a structured problem-resolution workflow with safety-relevance tagging and verified closure. The deliverables an auditor asks for — the software development plan, the architecture, the traceability matrix, the verification evidence — generate from the live data rather than getting assembled by hand before a submission.