What Is IEC 62304? Overview, IEC 62304 Certification + Compliance Tips

IEC 62304 software safety classification is titled “medical device software — software lifecycle processes”. This is a functional safety standard similar to IEC 61508.

Complying with the standard is critical for medical device software developers.

Here, we give an overview of what is IEC 62304, IEC 62304 software safety classification, how to receive an IEC 62304 certification, and compliance tips for software development teams.

Read along or jump ahead to the section that interests you the most:

➡️ improve med dev software WITH static analysis

What Is IEC 62304 Software Safety Classification / IEC 62304 Certification?

IEC 62304 software safety classification is a functional safety standard that covers safe design and maintenance of software. It provides processes, activities, and tasks to ensure safety. It 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.

The nine parts of IEC 62304 are:

• 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.

📕 Related Content: Learn how to get FDA approval for your medical devices.

Other Regulatory Standards for Medical Devices

The medical device industry is highly regulated worldwide.

Key regulatory standards for medical devices include:

• 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 IEC 61508 — the umbrella functional safety standard — as a source for good software development methods, techniques, and tools.

📕 Related Content: Learn more about how you can ensure the Functional Safety of your software.

What Is 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.

IEC 62304 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 to IEC 62304 Software Safety Classification 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.

This includes:

• 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.

Examples

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 Helix ALM. 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 Helix QAC and Klocwork. 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.

This includes:

• 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.

Examples

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 Helix ALM, 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 Helix Core.

You can reduce software maintenance by ensuring that code is written according to an established standard and by measuring code quality. Perforce static analyzers can do this for you.

Part 7 — Software Risk Management Process

Part 7 of the safety standard describes processes for software risk management.

This includes:

• 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.

Examples

With the safety standard, it’s important to show traceability from a hazardous situation to a risk control measure.

For example, you can use Helix ALM to identify hazards by doing a failure modes and effects analysis (FMEA). (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 traceability matrix.

Part 8 — Software Configuration Management Process

Part 8 of the safety standard describes processes for software configuration management.

This includes:

• 8.1: Configuration identification.
• 8.2: Change control.
• 8.3: Configuration status accounting.

Examples

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 static code analysis tool such as Helix QAC and Klocwork to check if the third-party software meets coding guidelines.

It’s also important to manage change. You can use software development tools — including Perforce static analyzers and Helix ALM — to manage changes through the software development lifecycle. Perforce static analyzers, 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.

This includes:

• 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.

Examples

Software problem resolution needs to be well-documented.

One example is test documentation. Helix ALM documents all testing efforts. And tests can be traced to specific requirements or identified problems.

📕 Related Content: Learn more about how to ensure your medical device development process is efficient.

What Is 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.

Helix QAC, for instance, is certified by SGS-TÜV Saar for use in the development of safety-critical systems. While Klocwork has been certified by TÜV-SÜD for functional safety compliance. Both 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 with IEC 62304 and beyond.

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 Helix ALM — 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.

➡️ start your free Helix ALM trial

Enforcing IEC 62304 with Static Analysis

Coding standards 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 MISRA, are particularly effective in safety-critical development.

Using a static analysis tool — like Helix QAC or Klocwork — 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 or Klocwork will help you accelerate compliance.

➡️ This way to your free static analysis triaL