Background

Software is becoming an increasingly important aspect of medical devices as it enables highly complex systems to be built. However, medical devices are built within a regulatory environment, and complexity is an enemy of safety.

Therefore, documented processes are important for adherence to medical device regulatory requirements. Medical devices can only be marketed if compliance with standards (e.g. GAMP 5, GAMP 4, ISO 14971, IEC 62304, BS EN 60601, IEC 60812, TIR32, AAMI) and guidance from appropriate regulatory bodies is achieved (e.g. Food and Drug Administration (FDA) & European Council). Due to the safety-critical nature of medical device software it is important that highly efficient software practices are in place within medical device companies. In fact, integrated into the design process of medical devices, there is requirement to produce and maintain a device technical file which incorporates a design history file. Design history illustrates the well documented, defined and controlled processes and outputs, undertaken in the development of medical devices (including the software components).

According to the Institute of Medicine report ‘To Err is Human’ between 44000 to 98000 people die in hospital from preventative medical errors. The report also says that more people die every year as a result of medical errors than from motor vehicle accidents, breast cancer or AIDS. The use of software in medical devices has become widespread in the last two decades. Medical devices with software include those that are supplied and used entirely in hospitals and other health facilities, as well as consumer items such as blood pressure monitors. Many medical devices, and their software, operate in real time – monitoring, diagnosing, or controlling a physiological process as it changes.

Analysis of medical device recalls highlights the diverse nature of medical device software failures. The FDA found that approximately 44% of the quality problems that led to voluntary recalls of medical devices were attributed to errors or deficiencies designed into particular medical devices rather than having been inserted during the manufacturing phase. In the medical device industry, the software used to control a device takes on an additional role - it must help ensure the safety of the user. There are many challenges to implementing safe software. Software design needs to include deliberate engineering practices requiring rigorous risk analysis and mitigation to be performed whilst at the same time simultaneously addressing potential device failures that may be introduced by the software itself.

The main area of concern, particularly for small medical device companies in relation to their software development practices is to ensure that the elements required by the FDA are in place rather than trying to improve their overall software development practices. GAMP details practices that medical device companies may adopt in order to comply with medical device regulations, however no standards exist within the medical device domain in relation to how such practices could be improved by incorporating practices from formal software engineering reference models. Previous research has investigated the suitability of using existing software quality assurance standards in order to achieve FDA compliance related to the areas of process management, requirements specification, design control and change control. However, no specific software process improvement (SPI) reference model has been developed for the industry. If we investigate other regulated industries such as the automotive and space industries we realise that these domains are not content with satisfying regulatory standards, but have proactively developed SPI models specifically for their domain so that they may continuously improve the development of their information systems to achieve higher levels of safety, greater efficiency, and a faster time to market, whilst seamlessly satisfying regulatory quality requirements. The major SPI models that currently exist, namely ISO/IEC 15504 and CMMI do not address the regulatory requirements of either the medical device, automotive or space industries. Therefore, a new SPI model was developed specifically for the automotive industry, this model was based upon ISO/IEC 15504 and is referred to as Automotive Spice. Likewise, a new ISO/IEC15504 based SPI model was developed specifically for the space industry, this model is known as SPiCE for SPACE. Both of these models contain reference and assessment information in relation to how companies may improve software development practices within their domain.

Of particular importance to medical device companies is the need to develop medical devices in full compliance with the appropriate regulatory bodies that govern the sale and marketing of medical devices throughout the world. The key business goals of cost effective development and speed to market, are fundamental factors for all companies, but for small new-start companies this is critical.