This is a ready-to-use worksheet for the single most consequential decision in an IEC 62304 project: assigning the software safety class (A, B, or C) to every software item, and defending that assignment with a documented, hazard-driven rationale. Replace every <<FILL: ...>> placeholder with your own specifics. A worked filled specimen follows, built on a closed-loop dosing example so you can see how a real, defensible classification reads. This worksheet is educational structure to adapt, not legal or regulatory advice; confirm the current IEC 62304 class definitions and your own architecture against the standard itself before you rely on it, and route the completed assessment through your normal document control and risk-management-file process.
Document control header
| Field | Entry |
|---|---|
| Document title | IEC 62304 Software Safety Classification |
| Document number | <<FILL: RA-ID, e.g. RA-SW-014>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Software system / product | <<FILL: SYSTEM NAME, e.g. companion dosing application>> |
| Parent risk management file | <<FILL: ISO 14971 risk management file reference>> |
| Assessor(s) | <<FILL: name, role>> |
| Date | <<FILL: date>> |
1. Purpose
This worksheet assigns an IEC 62304 software safety class to each item of <<FILL: SYSTEM NAME>>, argues any segregation claim used to keep an item at a lighter class, and produces a rationale an auditor or Notified Body reviewer can walk in either direction, from item to hazard and from hazard to item. It is filled at the architecture stage and re-run whenever the architecture changes.
2. Scope
This assessment covers <<FILL: the software system or systems in scope, and the release or version they apply to>>. It classifies software items and, where the architecture decomposes further, units. It does not itself perform the device-level hazard analysis; it consumes the hazards already identified in the ISO 14971 risk management file referenced above and determines which software items contribute to which hazards.
3. Methodology
- Enumerate the software items. Decompose the system per the architecture document into the items (and, where relevant, units) that will each carry a single classification.
- For each item, identify the credible failure modes. What can this item do wrong: wrong output, no output, delayed output, corrupted data, silent failure?
- For each failure mode, determine the worst credible harm, assuming the item fails and assuming that any risk control measures implemented in software, in the same item, do not work. Risk controls external to the software, a hardware interlock, an independent monitor, a clinician confirmation step outside this item, may be considered if they are genuinely independent of this item’s failure.
- Assign the severity band and the resulting class using the definitions in the current edition of IEC 62304 for Class A (no path to injury), Class B (a failure could cause a non-serious injury), and Class C (a failure could cause death or a serious injury). Confirm the exact wording in the standard for any borderline call; do not reason from memory on a close case.
- Check coupling. If this item shares a process, shared memory, or an unmediated interface with a higher-class item such that a fault in the higher-class item could reach this one, this item inherits the higher class unless segregation is argued and evidenced per section 4.
- Record the rationale. Every class assignment carries a written reason tied to a specific failure mode and a specific hazard, not a general statement.
- Re-run on architecture change. A refactor, a new interface, or a change in how items share resources can silently raise a class. Re-derive the classification whenever the architecture document changes, not only at major releases.
4. Segregation argument requirements
A segregation claim (keeping an item at a lighter class than an item it is coupled to) is only as strong as the evidence behind it. Do not accept a segregation claim unless all of the following are documented:
| Requirement | What “met” looks like |
|---|---|
| Independent execution context | Separate process, container, partition, or core, not merely a separate module in the same address space |
| Verified interface | The interface between the items is defined, bounded, and tested, including behavior on malformed or out-of-range input from the higher-class item |
| No uncontrolled shared resource | Shared memory, shared files, or shared hardware between the items is either absent or access-controlled and tested |
| Failure-injection evidence | A test that deliberately faults the higher-class item and confirms the lower-class item is unaffected, or an equivalent architectural analysis |
| Independent review | Someone other than the item’s own architect reviewed and signed the segregation argument |
A segregation claim with any row unmet does not hold; classify the coupled item at the higher class until the gap is closed.
5. Classification worksheet
| Item ID | Item / function | Credible failure mode(s) | Worst credible harm (external risk controls absent) | Severity band | Initial class | Coupled to a higher-class item? | Segregation evidenced (section 4)? | Final class | Rationale |
|---|---|---|---|---|---|---|---|---|---|
<<FILL: ITEM-01>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: none / non-serious / serious-or-death>> | <<FILL: A/B/C>> | <<FILL: Y/N, which item>> | <<FILL: Y/N/N-A>> | <<FILL: A/B/C>> | <<FILL>> |
<<FILL: ITEM-02>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: ITEM-03>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
6. Acceptance criteria
- Every software item in the architecture has a row and a final class; nothing is left unclassified.
- Every class assignment carries a severity rationale tied to a specific failure mode and a specific hazard, not a generic statement.
- Every segregation claim used to keep an item below the class of something it is coupled to satisfies all five requirements in section 4, with evidence referenced, not merely asserted.
- The classification is consistent with the architecture document as issued; if they disagree, one of them is wrong and must be corrected before release.
- The process artifacts actually produced for each item match what its class requires (a Class C item without a detailed design record or unit verification evidence is a gap, not a judgment call).
- The assessment is re-run and the record updated whenever the architecture changes in a way that could affect coupling or segregation.
7. References
IEC 62304, Medical device software, Software life cycle processes (current edition, currently 2006+AMD1:2015; confirm status of any newer edition before citing). ISO 14971, Medical devices, Application of risk management to medical devices (current edition). IEC/TR 80002-1, guidance on the application of ISO 14971 to medical device software.
Confirm the current edition and exact class definitions of IEC 62304 before issue; this worksheet paraphrases the standard’s structure and does not reproduce its text.
8. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessor (Software) | <<FILL>> | ||
| Risk Management reviewer | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
Filled specimen
The following completes the worksheet for the closed-loop glucose management example used throughout the companion article: a dosing recommendation engine, a trend display, and a settings module, first without a segregation argument and then with one.
Without segregation (dosing engine and display share a process and memory):
| Item ID | Item / function | Credible failure mode(s) | Worst credible harm | Severity band | Initial class | Coupled to a higher-class item? | Segregation evidenced? | Final class | Rationale |
|---|---|---|---|---|---|---|---|---|---|
| ITEM-DOSE | Dosing recommendation engine | Miscalculated dose value; stale sensor data used | Severe hypoglycemia, potentially fatal | Serious/death | C | N/A | N/A | C | Direct path from a calculation fault to a life-threatening overdose or underdose; no external control independent of this item prevents it |
| ITEM-TREND | Trend display and history charts | Rendering fault shows incorrect trend | Misleading a clinical decision made with other information | Non-serious | B | Y, ITEM-DOSE (shared process and memory) | N, no verified partition or fault-injection evidence exists yet | C | A crash or memory corruption in ITEM-DOSE can propagate to ITEM-TREND in the current architecture; inherits Class C until segregated |
| ITEM-SET | Settings and account management | Incorrect setting stored or displayed | Administrative inconvenience only | None | A | N | N/A | A | No credible path from this item’s failure to patient harm |
With segregation implemented (separate processes, verified interface, fault-injection test passed):
| Item ID | Item / function | Credible failure mode(s) | Worst credible harm | Severity band | Initial class | Coupled to a higher-class item? | Segregation evidenced? | Final class | Rationale |
|---|---|---|---|---|---|---|---|---|---|
| ITEM-DOSE | Dosing recommendation engine | Miscalculated dose value; stale sensor data used | Severe hypoglycemia, potentially fatal | Serious/death | C | N/A | N/A | C | Unchanged; the dosing engine’s own worst-case failure is still fatal |
| ITEM-TREND | Trend display and history charts | Rendering fault shows incorrect trend | Misleading a clinical decision made with other information | Non-serious | B | Y, ITEM-DOSE | Y, separate OS process, defined message-passing interface with bounds checking, fault-injection test FI-2026-004 confirms a forced crash in ITEM-DOSE does not affect ITEM-TREND, reviewed by an architect who did not write either item | B | Segregation argument meets all five requirements in section 4; the lighter class is defensible |
| ITEM-SET | Settings and account management | Incorrect setting stored or displayed | Administrative inconvenience only | None | A | N | N/A | A | Unchanged |
The difference between the two tables is the whole point of this worksheet: the same display module is Class C or Class B depending entirely on whether the segregation evidence actually exists, not on how the module itself behaves.
Common inspection findings this worksheet prevents
- A Class C labeling paired with Class A-depth documentation, or the reverse, a suspiciously light class for software that clearly touches dosing, diagnosis, or life support.
- A segregation claim asserted in a document with no fault-injection evidence, no independent review, or an interface that was never actually tested against malformed input.
- A classification that was never re-run after an architecture change, so the documented class no longer matches the as-built coupling between items.
- A class assignment with no rationale, or a rationale that cites the item’s normal function instead of its worst credible failure.
- Process artifacts that do not match the assigned class, most often a Class C item missing a detailed design record or independent unit verification.
How to adapt this worksheet
- Set your document number and link it to your risk management file in the header.
- Replace the item rows with your actual architecture decomposition; do not force a fixed number of rows, classify every item the architecture identifies.
- If you use a formal fault-injection test suite, reference the actual test IDs and reports in the segregation column rather than a narrative description.
- Route the completed worksheet through the same review and approval chain as your architecture document, since the two must stay consistent.
- Confirm the current IEC 62304 edition and class definitions against the standard before issue, and note in section 7 which edition you classified against.