What Is IEC 62304? Compliance Tips For Medical Device Software Developers
IEC 62304 is titled “medical device software — software lifecycle processes”. This is a functional safety standard derived from .
Complying with this standard is critical for medical device software developers.
Here, we give an overview of the standard, software safety classifications, and compliance tips for software development teams.
IEC 62304 Overview
IEC 62304 applies to the development and maintenance of medical device software when:
- The software is itself a medical device.
- Or the software is an embedded or integral part of the final medical device.
What IEC 62304
This standard covers safe design and maintenance of software. It provides processes, activities, and tasks to ensure safety.
There are nine parts of the safety standard:
- Part 1: Scope.
- Part 2: Normative references.
- Part 3: Terms and definitions.
- Part 4: General requirements.
- Part 5: Software development process.
- Part 6: Software maintenance process.
- Part 7: Software risk management process.
- Part 8: Software configuration management process.
- Part 9: Software problem resolution process.
It’s assumed that you use a quality management system and risk management system.
Other Regulatory Standards for Medical Devices
The medical device industry is highly regulated worldwide.
Key regulatory standards for medical devices include:
- IEC 62304 — the subject of this blog.
- ISO 13485 — quality management.
- ISO 14971 — risk management.
- EU Medical Device Regulation — EU standard which replaces Medical Devices Directive in 2020.
- FDA regulations — U.S. standards for medical device compliance.
Annex C documents the relationship to other standards.
The standard also refers to — the umbrella functional safety standard — as a source for good software development methods, techniques, and tools.
IEC 62304 Software Safety Classification
It’s important to ensure safety from the start of development. Product testing isn’t enough to ensure patient safety. And patient safety is critical. Plus, building safety into your processes early on saves time and expense later.
Software safety classification in the standard determines the safety-related processes you’ll need to use. This impacts the entire software development lifecycle — from requirements and coding to release and maintenance.
The standard defines three safety classes for software:
- Class A: No injury or damage to health is possible.
- Class B: Injury is possible, but not serious.
- Class C: Death or serious injury is possible.
Compliance Tips for Software Developers
Complying with the safety standard is important for medical device software developers. And complying with this international standard satisfies the requirements of other regional standards.
In the EU, it satisfies key requirements in the Medical Devices Directive (soon to be replaced by EU Medical Device Regulation). And, in the U.S., the FDA accepts the standard's compliance as proof that regulatory processes have been fulfilled, such as 501(k).
Accelerate Compliance With Software Development Tools
To comply with the safety standard, processes need to be well-documented. And using software development tools can help you document and accelerate compliance.
Part 5 — Software Development Process
Part 5 of the safety standard describes processes for software development.
- 5.1: Development planning.
- 5.2: Requirements analysis.
- 5.3: Architectural design.
- 5.4: Detailed design.
- 5.5: Unit implementation and verification.
- 5.6: Integration and integration testing.
- 5.7: System testing.
- 5.8: Release.
Each process includes activities and tasks that must be completed for each medical device class.
Using software development tools can help in fulfilling these requirements.
It’s required to establish tests for software requirements for Class B and Class C. You can fulfill this requirement by using an ALM tool, like . For example, you’ll be able to generate test cases based on requirements — and create a requirements traceability matrix.
Class B and Class C software also need to establish a software unit verification process. You can fulfill this requirement by using a static code analyzer, such as . For example, you’ll be able to verify code against a coding standard — and ensure safe, secure, and reliable software.
Part 6 — Software Maintenance Process
Part 6 of the safety standard describes processes for software maintenance.
- 6.1: Establish software maintenance plan.
- 6.2: Problem and modification analysis.
- 6.3: Implementation of modifications.
It’s important to take user feedback and resolve issues in the maintenance phase.
Using software development tools can help you ensure safety in the maintenance process.
For instance, there’s a requirement to establish a software maintenance plan. You can use software, such as , to document that plan.
Managing change is key in the maintenance process. Using Helix ALM gives you visibility into change across the software development lifecycle. Especially when paired with a version control system, such as .
You can reduce software maintenance by ensuring that code is written according to an established standard and by measuring code quality. Helix QAC can do this for you.
Part 7 — Software Risk Management Process
Part 7 of the safety standard describes processes for software risk management.
- 7.1: Analysis of software contributing to hazardous situations.
- 7.2: Risk control measures.
- 7.3: Verification of risk control measures.
- 7.4: Risk management of software changes.
With the safety standard, it’s important to show traceability from a hazardous situation to a .
For example, you can use Helix ALM to identify hazards by doing a . (This is also important for compliance with ISO 14971.)
You can then use the tool to connect the hazard to its appropriate risk control measure. And you can automate this by using a .
Part 8 — Software Configuration Management Process
Part 8 of the safety standard describes processes for software configuration management.
- 8.1: Configuration identification.
- 8.2: Change control.
- 8.3: Configuration status accounting.
The safety standard cautions against Software of Unknown Provenance (SOUP). SOUP is third party software. It includes open source libraries and operating systems. And Part 8 includes a requirement to identify SOUP (for all medical device classes). You can use a tool such as Helix QAC to check if the third-party software meets coding guidelines.
It’s also important to manage change. You can use software development tools — including and — to manage changes through the software development lifecycle. Helix QAC, for instance, can show differences in coding defects present between different versions of code.
Part 9 — Software Problem Resolution Process
Part 9 of the safety standard describes process for software problem resolution.
- 9.1: Prepare problem reports.
- 9.2: Investigate the problem.
- 9.3: Advise internal parties.
- 9.4: Use change control process.
- 9.5: Maintain records.
- 9.6: Analyze problems for trends.
- 9.7: Verify software problem resolution.
- 9.8: Test documentation contents.
Software problem resolution needs to be well-documented.
One example is test documentation. documents all testing efforts. And tests can be traced to specific requirements or identified problems.
IEC 62304 Certification
It’s easier to get certified for compliance when you have the right development tools. And it’s even easier when those tools have already been certified by an independent organization.
, for instance, is certified by SGS-TÜV Saar for use in the development of safety-critical systems. It can be supplied with a tool certification kit, which makes the path to compliance much simpler.
Software Development Tools From Perforce
Here’s how software development tools from Perforce simplify and accelerate safety standard compliance.
Application Lifecycle Management
Managing requirements, tests, and issues effectively is important for medical device software developers. These items need to be documented in order to comply with safety standards.
Using an application lifecycle management tool — like — helps you accelerate compliance by:
- Managing risk with FMEA.
- Creating a requirements traceability matrix.
- Documenting testing efforts.
See how Helix ALM will help you prove compliance in record time. Try it free for 30 days.
Static Code Analysis
are a key part of software acceptance criteria.
Annex B.5.5. states:
“To consistently achieve the desirable code characteristics, coding standards should be used to specify a preferred coding style. Examples of coding standards include requirements for understandability, language usage rules or restrictions, and complexity management.”
Coding standards, such as , are particularly effective in safety-critical development.
Using a static code analyzer — like — helps you accelerate compliance by:
- Enforcing coding standards and detecting rule violations.
- Detecting compliance issues earlier in development (and accelerating code reviews/manual testing efforts).
- Reporting on compliance over time and across product versions.
See how Helix QAC will help you accelerate compliance. Request a trial to learn more.