IEC 62304

What Is IEC 62304?

IEC 62304 is a safety standard that specifies requirements for medical software and software within medical devices during their lifecycles. It is a global standard published by the International Electrotechnical Commission (IEC), an organization dating back to 1906. It is recognized worldwide, with most nations participating as affiliates, associate members, or full members. The IEC’s standards are generally adopted nationally by its members, making IEC 62304 a strong foundation for medical software lifecycle requirements in every country.

Benefits of IEC 62304

The IEC 62304 standard covers processes, activities, and tasks, establishing a common framework for the lifecycle of medical software. Compliance is critical for software developers because the medical device industry is highly regulated—for example, through the ISO 13485 quality management and ISO 14971 risk management standards. These regulations protect the public from the risk of harm from the provision of health and social care services.

IEC 62304 covers the safe design and maintenance of medical device software, in which the software is either itself a device or is embedded in a medical device. This ensures that medical device software is safe for medical professionals delivering a therapeutic service to patients.

IEC 62304 Classifications

The IEC 62304 defines three classes for patient safety, defining the processes used during the entire lifecycle, from initial requirements to code release and maintenance:

Class A: the highest level, in which no damage to patient health is possible from the medical software

Class B: the middle level, in which some injury could be possible but not severe

Class C: the lowest level, in which serious injury or even death might result from the use of the medical software

How IEC 62304 Works

Aside from ISO standards 13485 and 14971, IEC 62304 refers to the EU Medical Device Regulation from 2020 and various US FDA regulations. It is related to the more general IEC 61508 umbrella functional safety standard. To comply with IEC 62304, a medical software’s processes and development must be well documented.

Compliance requirements include following a development process that adheres to strict guidelines for planning, requirement analysis, architectural design, unit implementation and verification, integration testing, and the final code release strategy. For Classes B and C, software unit verification is required as well.

The software’s maintenance regime must also comply with IEC 62304, including a plan for updates, analysis of problems and necessary modifications, and a plan for implementing changes.

Further compliance is required for risk management, including contributions to hazardous situations, associated control measures, and their verification. Software changes during maintenance must also be assessed for risk.

Finally, there are IEC 62304 processes defined for software configuration alongside the discovery, reporting, and resolution of problems.

Compliance with the development, maintenance, risk management, configuration and problem mitigation for medical software defined by IEC 62304 results in certification, which confirms that the code meets this rigorous patient safety standard.IEC 62304 covers the safe design and maintenance of medical device software, in which the software is either itself a device or is embedded in a medical device. This ensures that medical device software is safe for medical professionals delivering a therapeutic service to patients.

IEC 62304 Vs. SOUP

Software of Unknown (or Uncertain) Provenance (or Pedigree), AKA SOUP, is code not developed with a known development process or methodology. It may have unknown or even no safety-enhancing properties. This means that it cannot directly comply with the IEC 62304 standard.

SOUP will generally consist of off-the-shelf or third-party software cheaper or faster for manufacturers to implement than developing original compliant code. SOUP may be proprietary, making it impossible to check the source code for compliance (i.e., the software is “black box”). Alternatively, it could be open source, whereby the software can be freely distributed and customized, but its origins and updates may not be clearly defined.

It is possible to use SOUP within broader IEC 62304-compliant software development, but additional controls will be required and associated risk accounted for. Some third-party software may already be pre-certified: QNX® OS for Safety is pre-certified to IEC 62304 Class C.

Rather than being a safety risk, SOUP can enhance safety as it may best-in-class for specific tasks, such as device drivers, user interface, or efficiency—all of which may not be the area of expertise for the medical software developer. A SOUP operating system can also come with a valuable ecosystem of application modules.

Achieving safety certification for an embedded system is time-intensive and costly. BlackBerry® QNX® reduces that burden for our customers by pre-certifying our real-time operating system and hypervisor to the highest automotive, industrial and medical standards. We also offer safety services, from maintenance and support through to flexible custom services plans. In this section, you’ll learn about our pre-certified software solutions and our safety services.

BlackBerry QNX has developed in-depth safety expertise and technology. In addition, having certified our own products to the highest levels of ISO 26262 (ASIL D) and IEC 61508 (SIL 3), as well as IEC 62304, we have the tools and experience to help get your embedded product across the finish line, too.

Check Out Our Other Ultimate Guides

Structural Dependency
Provides embedded RTOS basics and considerations when choosing between an open source or commercial OS options
Structural Dependency
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
Structural Dependency
Information about the UNECE WP.29 regulations, the countries where they apply and how they aim to mitigate the cybersecurity risks posed to passenger vehicles.
Structural Dependency
Defines autonomous systems and the various levels of autonomy
Read the Guide