IEC 62304 Compliance for Medical Device Software
Medical device software can perform correctly during demonstration and still fall short during regulatory review. Reviewers need evidence showing that requirements, risks, architecture, testing, release and maintenance were controlled throughout development.
IEC 62304:2006+A1:2015 provides the lifecycle framework for software that is itself a medical device or forms an embedded or integral part of one. It covers software development and maintenance, but does not independently establish complete device safety, usability, cybersecurity or clinical performance. The complete standard is recognised by the US FDA.
What IEC 62304 Requires Manufacturers to Control
IEC 62304 organises compliance around software development, maintenance, risk management, configuration management and problem resolution. These processes should operate as one connected system, not as separate documents prepared before an audit.
The Software Development Plan should define the lifecycle model, responsibilities, deliverables, review methods, configuration controls and verification strategy.
The Software Requirements Specification should contain clear, testable requirements for functionality, interfaces, alarms, calculations, data handling, error responses and risk controls. For higher-risk software, architecture and detailed design records should explain how software items, units, interfaces and data flows implement those requirements.
Software Safety Classification Determines Documentation Rigor
IEC 62304 uses three software safety classes. Class A applies when no injury or damage to health is possible. Class B applies when failure could contribute to non-serious injury. Class C applies when failure could contribute to death or serious injury.
Classification must be supported by the medical device risk analysis and should not be copied from the device’s regulatory class. The analysis assumes that software failure can occur. External controls may reduce the resulting class only when their independence and effectiveness are justified.
Class A is not exempt. Planning, requirements, system testing, release, maintenance, configuration management and problem resolution still require controlled evidence.
Build a Traceable Lifecycle Record
A compliant file should allow reviewers to follow each safety-related requirement from its origin to implementation and verification. Traceability commonly connects user needs, software requirements, risk controls, design elements, tests and results.
Manufacturers may use a matrix, lifecycle management platform or another controlled system.
The tested software version must also match the version used during usability validation, EMC evaluation and medical device testing. Differences between tested, submitted and released versions should be documented and assessed.
Verification Should Address Failure Conditions
Verification should progress through software unit, integration and system activities according to the applicable safety class. Test records should identify the requirement, configuration, method, expected result, actual result and associated anomaly.
Testing only normal workflows can leave important risks unaddressed. Boundary values, invalid inputs, interrupted communication, timing conditions and identified fault conditions should be evaluated where relevant.
Software verification should remain aligned with device-level documentation, especially when software controls essential performance under IEC 60601-1.
Manage SOUP and Third-Party Components
Software of Unknown Provenance, or SOUP, may include operating systems, open-source libraries, commercial components, drivers and legacy code.
Manufacturers should document the component name, exact version, purpose, dependencies, known anomalies and potential safety effect. Published defects and security vulnerabilities should be reviewed according to the component’s role and risk.
SOUP is not automatically unacceptable. The compliance gap appears when versions are unknown, updates are uncontrolled or known problems are not assessed within the finished medical device.
Release, Maintenance and Problem Resolution
Release records should identify the approved configuration, completed verification, unresolved anomalies and differences between tested and released versions. Each unresolved anomaly should be assessed for its possible effect on safety and effectiveness.
After release, complaints, field feedback, software defects and relevant security information should enter a controlled problem-resolution process. Each modification should be evaluated for changed requirements, new risks, regression testing and possible retesting.
A structured design change and retesting assessment helps determine whether an update affects basic safety, essential performance or previous EMC evidence.
Common IEC 62304 Documentation Gaps
Frequent gaps include unsupported safety classification, untestable requirements, incomplete architecture records, missing SOUP versions and weak traceability between risk controls and verification.
Other concerns include closing failed tests without investigation, uncontrolled Agile records, inadequate regression rationale and differences between tested and released configurations.
Reviewing the lifecycle file before formal testing can identify these issues earlier. The IEC 60601-1 pre-test documentation checklist can help identify software-related inputs affecting electrical safety and performance testing.
How Astute Labs Supports Software-Driven Medical Devices
Astute Labs supports Indian manufacturers in coordinating software lifecycle evidence with electrical safety, essential performance, EMC and device-level testing. Reviewing the software version, risk controls and applicable documentation before testing helps reduce inconsistencies between the technical file and tested device.
A controlled IEC 62304 lifecycle file does more than support a regulatory submission. It gives manufacturers a reliable basis for managing software changes, investigating field problems and demonstrating that safety-related functions remain controlled throughout the product lifecycle.
Astute Labs helps manufacturers identify software-related testing dependencies, prepare the required technical inputs and align the tested device configuration with the supporting compliance documentation. Contact us
