Software Life Cycle for Medical Devices: IEC 62304

The European Medical Device Regulation (EU) 2017/745 (MDR) and the In Vitro Diagnostics Regulation (EU) 2017/746 (IVDR) require manufacturers to consider the software life cycle of medical devices. If manufacturers want to implement this requirement in practice, 3 standards are particularly important. In this article, we discuss what manufacturers must pay attention to when considering the software lifecycle and how the standards specifically help in this respect.

You will find answers to the following questions:

  • What is a software life cycle for medical devices?
  • Is my software a medical device?
  • How do I implement the legal requirements for the software lifecycle of medical devices?
  • What does IEC 62304 describe?
  • What does IEC 82304-1 describe?
  • What does IEC 60601-1 describe?

Do you have a question?
We can answer many of your questions easily and quickly on the phone.
Please give us a call: +49 69 6308 367

What is a software life cycle for medical devices?

The life cycle of a product describes a process from the product idea to the market exclusion. This concept is also applied to software as a medical device. The European legislator obliges manufacturers to consider the principles of the product life cycle.

Specifically, the MDR contains four direct references to the life cycle of medical devices:

  • The manufacturer must keep the clinical evaluation and the associated documents up-to-date throughout the entire life cycle of the product (Article 61, MDR).
  • The manufacturer must carry out continuous risk management throughout the life cycle of the product (Annex I, MDR).
  • The manufacturer shall establish and maintain a quality management system throughout the life cycle of the product (Annex IX, MDR).
  • The manufacturer must apply for a type-examination from a Notified Body which shows that the product complies with the provisions of the MDR throughout its entire life cycle (Annex X, MDR).

Another 5th reference explicitly refers to software as a medical device. There it says:

In the case of products whose components include software or products in the form of software, the software is developed and manufactured in accordance with the state of the art, taking into account the principles of the software life cycle, risk management including information security, verification and validation”.

Annex I, MDR

Obviously, the law remains rather vague in its wording. How can manufacturers practically meet the legal requirements? And: When exactly is one a manufacturer and thus affected?

Is my software a medical device?

If manufacturers want to develop and market software as a medical device, they must comply with the aforementioned legal requirements and become affected.

The MDR also specifies what a medical device is. It primarily defines medical devices according to their areas of application (Article 2, MDR). These are:

  • diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of diseases,
  • diagnosing, monitoring, treating, alleviating or compensating for injury or disability,
  • examination, replacement or modification of the anatomy or a physiological or pathological process or condition, and
  • obtaining information by in vitro examination of samples taken from the human body, including organ, blood and tissue donations.

In addition, products for contraception or contraception as well as for cleaning, disinfection or sterilisation are medical devices within the meaning of the law.

Medical devices must also be intended for human beings. The active principle is also important. Medical devices work in or on the human body, but not pharmacologically, metabolically or immunologically.

Software can be a medical device if it has a medical purpose. In addition to devices, instruments, apparatus, etc., the MDR expressly refers to software. However, it does not define medical software.

Our article “Software Classification: Insights in EU Guidance” provides a detailed explanation of the definition and classification of medical software. This is currently under discussion in expert circles.

Overall, however, the MDR makes it clear that medical software must be able to do more than just” search, store, archive or transmit. In particular, it interprets data and helps to make diagnoses and initiate therapies.

This means, for example, that patient data management systems, hospital information systems or medical learning and teaching programs are not medical products.

How do I implement the legal requirements for the software lifecycle of medical devices?

In Annex I, the MDR defines the general requirements for safety and performance of medical devices. If a manufacturer intends to market software as a medical device, he must prove that he meets these requirements.

The following 3 standards are particularly helpful for practical implementation:

IEC 62304

The standard “Medical Device Software – Software Life Cycle Processes” (IEC 62304) is the first standard to be considered when looking at the software life cycle. The standard describes life cycle processes and assigns certain activities and tasks to them.

It applies to the development and maintenance of medical software. It does not matter whether the software itself is a medical device or whether it is used as an embedded or integral part of a medical device.

The application of the standard presupposes that the manufacturer develops and maintains his software as part of a quality management and risk management system.

IEC 82304-1

Another standard “Health software – General requirements for product safety” (IEC 82304-1) is also important. It relates to questions about the safety and risks of software that is to be marketed independently of hardware (“stand-alone software”, “health apps”).

A health app can also be a medical device. The standard describes the requirements for manufacturers and covers the entire life cycle. This includes design, development, validation, installation, maintenance and disposal.

The scope of application is thus more comprehensive than that of IEC 62304. The standard also describes higher-level requirements that go beyond pure software development. There is also a recognizable focus on security.

IEC 60601-1

In addition to the two standards mentioned above, the standard “Medical electrical equipment – Part 1: General requirements for safety, including essential performance (IEC 60601-1)” plays a role as the central standard for electromedical equipment.

Chapter 14 deals with “Programmable electrical medical systems (PEMS)” and provides the general framework for a life cycle assessment of medical software.

Currently, a second version of IEC 62304 is in consultation. The aim of this standard development is to create a uniform framework for all software types.

Altogether, independent or device-related software can be differentiated, each with a medical or (only) health-related purpose, each operating on a specific or general hardware platform.

What does IEC 62304 describe?

The IEC 62304 process standard describes 5 basic software processes:

  • development
  • maintenance
  • risk management
  • configuration
  • problem resolution

Software development process

At the beginning of the software development a planning takes place. The manufacturer prepares a detailed software development plan, which he must keep up to date depending on development progress.

The manufacturer then analyzes the software requirements. This includes features such as time behavior, operating system, memory size, default settings, interfaces, authentication, network protocols and much more.

The manufacturer must then design a suitable software architecture and subsequently describe how he intends to implement and integrate the software.

IEC 62304 explains the requirements for the software architecture in detail.

These include, for example, interfaces between components and special requirements for “unknown” software components. The standard describes such components as SOUP, “Software Of Unknown Provenance” or “Off-The-Shelf-Software”. This is generally available software that has not been developed for the respective medical device.

From the point of view of risk management, SOUP naturally faces special challenges. It is therefore not surprising that the development process also includes a description of software testing. The software development process concludes with information on documentation and archiving.

Software maintenance process

The software maintenance process begins with a maintenance planning that includes, for example, procedures for receipt, documentation, and traceability.

IEC 62304 then requires a systematic analysis of problems and changes that have occurred in connection with the software application. This includes appropriate communication with users and responsible authorities. Finally, the standard describes how changes must be implemented and released in an orderly manner.

Software risk management process

It comes as no surprise that risk management first contains a hazard analysis. The focus is on components that could contribute to a hazard situation and their causes.

It should be noted that there cannot be any accidental errors with software, such as can occur with physical medical devices due to the inferior quality of a delivered and processed material or due to errors due to the carelessness of employees in production.

If a software contains an error, all copies of this version of the software, unlike a physical medical device, are affected by this error. Software errors are therefore always systematic errors.

Again, SOUP plays an important role, because the standard explicitly requires an evaluation of publicly available lists with “SOUP anomalies”.

The hazard analysis is followed by a consideration of risk control measures, their verification and traceability documentation. Manufacturers should also explicitly consider and organize the risks of software changes.

Software configuration management process

IEC 62304 does not leave the correct configuration of medical software to chance. A detailed breakdown of identification, documentation and approval steps ensures that the manufacturer can find, adapt and trace the best possible configuration. The process in turn includes a special consideration of SOUP.

Software problem resolution process

The standard requires that the manufacturer reports, investigates and informs involved parties of problems arising in connection with the use of medical software. The manufacturer should also keep all records and also conduct a trend analysis of software problems. The process concludes with audit documentation.

IEC 62304 also requires manufacturers to classify the risks of their medical software. The standard specifies a 3-class model consisting of safety classes A, B and C for this purpose. The safety classes depend on the contribution of the software to a hazardous situation. Manufacturers apply the processes described above depending on the respective security class.

What does IEC 82304-1 describe?

The standard first describes a number of requirements for health apps:

  • risk management requirements (e.g. with regard to purpose and user profile),
  • user requirements (e.g. regarding information security and software support),
  • system requirements (e.g. in terms of interoperability and performance).

This is followed by an analysis of the software lifecycle process. Here, the standard refers directly to IEC 62304.

In addition, IEC 82304-1 describes the validation of health apps and instructs manufacturers to formulate corresponding accompanying documents. The accompanying documents should include the following contents:

  • operating instructions with description of the Health App
  • security alerts
  • installation guide
  • switch-on and switch-off procedures
  • operating instructions
  • notifications
  • decommissioning
  • technical description, e.g. for network integration

Finally, the standard describes the conditions for all activities of the manufacturer after placing a health app on the market. This naturally includes appropriate maintenance and servicing of the software as well as re-validation and orderly decommissioning at the end of the life cycle.

Defined processes are also important when it comes to documenting any errors or problems and communicating them to the responsible authorities.

What does IEC 60601-1 describe?

In Chapter 14, IEC 60601-1 supplements the existing requirements for the risk management process and life cycle assessment with the necessary aspects of medical software (programmable electrical medical systems, PEMS).

This includes additions to the following PEMS aspects:

  • documentation
  • risk management plan
  • development lifecycle
  • oroblem solution
  • risk management process
  • requirement specification
  • architecture
  • design and execution
  • verification
  • validation
  • modification
  • integration into IT networks

IEC 60601-1 proposes in Annex H a model of a development life cycle for PEMS. The model is based on the established V-model for software development and is divided into a decomposition and an integration process.

Starting with the user needs, the model describes different software specification and development steps in a layered representation, which are subsequently combined for software verification and validation. The model sets the individual steps in relation to risk management.

IEC 60601-1 extends the risk management process by software-specific aspects, especially with regard to data, such as

  • data availability
  • data integrity
  • data error
  • data time assignment
  • data security

The integration of software into IT networks naturally requires special precautions in terms of security and risk management. IEC 60601-1 explicitly addresses this aspect.

The standard requires, for example, that the purpose of the integration, the characteristics and the configuration of the network be documented. In addition, the distributor should draw the user’s attention to the risks arising from network integration.

Summary

We recommend that medical software manufacturers study the practical application of the IEC 62304, IEC 82304-1 and IEC 60601-1 standards in detail in order to comply with legal requirements.

Write a comment or suggest a term!