IEC 62304 requires medical device software to be classified based on the potential for contributing to hazardous situations. The classification determines the rigor of software development processes, documentation, and testing required.
Class A
No injury possible
Class B
Non-serious injury
Class C
Death/serious injury
IEC 62304:2006/AMD1:2015 - Medical Device Software Life Cycle Processes
Defines the framework for software development, including planning, requirements, design, implementation, testing, and maintenance. The 2015 amendment (AMD1) refined the classification process and clarified that risk controls can be used to reduce the software safety class.
FDA Software Guidance
FDA recognizes IEC 62304 and expects software safety classification in 510(k) submissions. The level of documentation required in regulatory submissions generally aligns with the IEC 62304 class. Class C software typically requires the most extensive documentation.
EU MDR and Software
Under EU MDR 2017/745, software is explicitly recognized as a medical device. Classification rules (Annex VIII, Rule 11) consider intended purpose and risk. IEC 62304 compliance is presumed to satisfy software-related requirements.
Key Considerations:
Perform hazard analysis per ISO 14971 to identify all hazardous situations the device could contribute to.
Determine which software items could contribute to each hazardous situation through malfunction or incorrect output.
For each hazardous situation, determine if it could result in death/serious injury (Class C) or non-serious injury (Class B).
Hardware risk controls outside the software item may reduce the class if they reliably prevent the hazardous situation.
| Process | Class A | Class B | Class C |
|---|---|---|---|
| Software Development Planning | ● | ● | ● |
| Software Requirements Analysis | ○ | ● | ● |
| Software Architectural Design | ○ | ● | ● |
| Software Detailed Design | ○ | ● | ● |
| Software Unit Implementation | ○ | ● | ● |
| Software Unit Verification | ○ | ● | ● |
| Software Integration Testing | ○ | ● | ● |
| Software System Testing | ○ | ● | ● |
| Software Release | ○ | ● | ● |
| Software Configuration Management | ● | ● | ● |
| Software Problem Resolution | ● | ● | ● |
| Software Risk Management | ○ | ● | ● |
Not considering worst-case scenarios or cascading failures. Remember: classification is based on what could happen, not what is likely to happen.
Software that provides diagnostic information can contribute to hazards through misdiagnosis, even if it doesn't directly control therapeutic actions.
Risk controls that reduce software class must be documented and validated. Hardware controls must be independent of the software being classified.
Third-party libraries, operating systems, and frameworks (SOUP) inherit the class of the software item that uses them for safety-related functions.
Interactive decision tree for software safety classification
| Requirement | Class A | Class B | Class C |
|---|---|---|---|
| Software Requirements Spec | Optional | Required | Required |
| Architecture Document | Optional | Required | Required + Safety |
| Unit Testing | Optional | Required | Required + Metrics |
| Code Review / Static Analysis | Not Required | Not Required | REQUIRED |
| Traceability Matrix | Not Required | Req → Test | Req → Code → Test |
| SOUP Evaluation | Minimal | Standard | Enhanced |
| Risk Management | Limited | Full Process | Enhanced Rigor |
Important Notes
Classification per IEC 62304:2006/AMD1:2015. Risk controls outside the software may reduce the class. Final classification should be documented in the Software Development Plan and approved by qualified personnel with consideration of the complete risk management process per ISO 14971.