Homepage / Scientific Articles / Medical device software standard IEC 62304 et al.

Medical device software standard IEC 62304 et al.

Medical device software standard IEC 62304 et al.
Medical device software standard IEC 62304 et al.

Methods of maintaining software quality and complying with regulatory requirements.

Today,computerized systems are found in all areas of regulated industry, from corporate software to applications such as LIMS, MES, CAQ to control and sensor systems in production facilities and monitoring systems.

For both pharmaceuticals as well as medical devices, legally compliant operation of the computerized systems involved is required by law. Whether and to what extent these systems have to be validated must be determined based on risk in each case. The validation strategy can be based on established approaches such as GAMP 5®. However, in the case of software that forms a part of a medical device or is itself deemed a medical device, GAMP 5® is not applicable; it explicitly excludes such systems.

Medical devices are systems and devices used for diagnosis, treatment or monitoring of patients. In the end, this is decided by the intended use. Apart from the statutory specifications for medical devices (such as the Medical Device Directive [MDD] or 21 CFR 820) the relevant harmonized standards for quality management (ISO 13485), risk management (ISO 14971), electrical safety (IEC 60601) and usability (IEC 62366) apply. Medical device software is regulated in the harmonized standard IEC 62304 from 2006.

Section B.1.1. states: «The purpose of this standard is to provide a development process that will consistently produce high-quality, safe medical device software.»

 

Processes of the standard IEC 62304
The standard IEC 62304 focuses on the software development process and also defines the typical activities of the system life cycle such as planning, requirements analysis, design, implementation, verification/testing and release.

The standard describes process and documentation requirements for each phase of the software life cycle.
Five processes are described, with which manufacturers can develop medical device software:

  1. software development process
  2. software maintenance process
  3. software risk management process (includes a reference to ISO 14971)
  4. software configuration management process
  5. software trouble-shooting process

While the standard IEC 62304 does not stipulate a specific process model for the software development process (e.g. waterfall model, V model, agile methods), it does contain requirements for specific activities, particularly for the documentation of

  • software requirements,
  • software architecture and the detailed design,
  • verification of the software units,
  • integration and system testing,
  • software approval and release.

These activities actually represent minimum requirements for contemporary software development. The IEC 62304 software risk management process requires that criticality is always evaluated, i.e. the extent to which the software could be the cause of a hazardous situation. This must be documented in the risk management cycles. Risk  control measures derived from this must be implemented, verified and documented in such a way that they are traceable to the software.

A relatively large section is dedicated to the maintenance and trouble-shooting processes. It is noteworthy that many errors in medical devices originated with product upgrades. An analysis by the FDA of 3140 recalls of medical devices between 1992 and 1998 revealed that 242 (7.7%) were due to software errors. Of the software recalls, 192 (or 79% of them) were caused by errors accidentally introduced during upgrades. Thus, a clearly defined trouble-shooting process is required in order to localize any errors that occur and remedy them effectively. According to the FDA, the rate of software caused recalls between 2008 and 2012 was around 15%, meanwhile with main error cause due to software design flaws.

 

The concept of safety classes as defined in IEC 62304
To minimize the effort and expense involved in documentation the standard IEC 62304 defines so-called safety classes:

  • Class A: No injury or damage to health is possible.
  • Class B: No severe injury is possible.
  • Class C: Death or severe injury is possible.

The higher the safety class, the more completely the aforementioned specifications of the standard must be implemented. For example, IEC 62304 requires only the software specifications and software approval for Class A software; testing is not required. Please note that this classification is not a statement of probability, but deals only with consequences. So in principle even in software that is actually deemed to be non-critical, severe injury or even death is possible after all. This has led many manufacturers to classify all of the software in their medical devices as Class C in order to be prepared for any event. The standard uses three terms to describe the breakdown of a «software system» (top level). The software system can be a subsystem of the medical device or a stand-alone medical device. The lowest level, which is not broken down any further for the purposes of testing the software configuration management, is the «software unit». All levels of the compilation, including the top and bottom levels, can be designated as «software components». Thus, a software system consists of one or more software components and each software component consists of one or more software units or software components that can be further broken down. It is the responsibility of the manufacturer to establish the definition and granularity of the software components and software units. Manufacturers may assign parts («components») of the software system a lower classification if a hardware measure reduces the risk or they can provide evidence that the components are adequately delimited. The classification of medical device software must not be confused with the classification of medical devices as specified by the Medical Device Directive. A Class I medical device can contain software of Safety Class C; it is also possible for Class IIa medical devices to contain Safety Class A software.

IEC 62304 and validation
Requirements for software are only a part of the requirements for a programmable electrical medical system (PEMS). The figure shows a schematic diagram of a V model of PEMS development. The specifications of IEC 62304 apply only to the PEMS component level and below. Validation is defined as the «evaluation of whether a product meets the requirements for the intended purpose» (IEC 60601-1) and the «confirmation […] that the requirements for a specific intended use or a specific intended application have been met» (ISO 13485/ISO9001). That is, validation requires a clearly defined intended use and valid requirements for use. The test scenarios for the medical device as a whole must then cover all specifications for use in accordance with IEC 62366 and test all core tasks as well as all work steps involving risk. As IEC 62304 focuses particularly on software embedded in medical devices, strictly speaking only requirements for software verification are formulated, not for validation. For this, medical device manufacturers currently have to rely on the standard IEC 60601-1 or wait for the future standard IEC 82304 («Health Software»), which cover the top section of the V model in the figure and will also be applicable to so-called stand-alone software. The Chemgineering Business Designers support medical device manufacturers in GAP analyses and audit preparation as well as in the preparation and implementation of validation projects. Take advantage of the experience of our certified experts to implement the regulatory specifications for medical device software pragmatically, safely and reliably.

Dr. Peter Schober|Senior Consultant Efficient IT|Chemgineering - The Business Designers

 

 

 

 

Comments

No comments found.

Chemgineering Business Design AG | Binningerstrasse 2 | 4142 Münchenstein | T +41 61 467 89 00 | F +41 61 467 89 01 | www.chemgineering.com | info@chemgineering.com