Properly applying the standard to medical development and integrating third-party software will pay dividends down the road.
Editor’s note: This is a two-part article. Part 2 will focus on systemic problems.
For many years, the medical device industry has operated without a consistent and internationally recognised regulatory process. In the U.S., companies have needed compliance to FDA guidelines, which some have lambasted for unnecessary delay while others complain about its lack of rigor. Others heartily approve of the FDA, but argue for government legislation that gives the FDA more power to hold company executives responsible when they don’t follow the FDA guidelines with due diligence.
In Europe, government approval of a medical device is through its corresponding Competent Authority (CA). Although this process is said to be more rigorous than the U.S. guidelines, companies can typically get their products to market faster in Europe—a fact that galls American-based businesses.
With the ratification and update of IEC 62304, a standard for design of medical products recently endorsed by both the European Union and the U.S., medical developers throughout the world are asking if IEC 62304 should form the foundations of a medical device standard that enables all countries to follow good development practise and to produce high-quality software for the medical community.
Certainly, there’s no turning back in the adoption of medical devices as they have become essential to medical practitioners who use them constantly to diagnose with ease and accuracy. What’s needed is a universal development process that ensures the safety and quality of such devices. To address the need for quality software development, let’s look at the unique challenges associated with developing sound medical devices and how IEC 62304 addresses these challenges. We will then look at how to bring legacy products into compliance since another significant challenge involves upgrading legacy code without introducing errors that adversely affect the safety of the medical device.
Unique Med Device Development Challenges
Medical devices rely heavily on legacy software, often referred to as software of unknown pedigree (SOUP). This legacy software forms the basis of new developments, which may now be subject to new medical device requirements or modern coding standards imposed by government, client demands, or simply a policy of continuous improvement within the developer organization. The need to leverage the value of SOUP, while meeting new standards and further developing functionality, presents its own set of unique challenges.
An analysis of 3140 medical device recalls conducted between 1992 and 1998 by the FDA reveals that 242 (7.7%) are attributable to software failures. Of the software recalls, 192 (79%) were caused by software defects introduced after software upgrades. This clearly reveals that many of the medical device faults stem from product upgrades. The high percentage of errors introduced during product upgrade has caused government agencies responsible for the medical device regulation to focus not only on development, but on subsequent maintenance and the impact of software changes to the existing system.
In response to this, many companies are changing their approach to improve their software processes as well as to adopt IEC 62304. This standard introduces a risk-based compliance structure—Class A through C where the failure of Class C software could result in death or serious injury—that ensures that medical applications comply with the standards suitable for their risk assessment.
IEC 62304 Focuses on Five Software Processes
The IEC 62304 standard provides a framework of software development lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. This standard basically identifies five main processes:
IEC 62304 Software Development Lifecycle
IEC 62304 focuses on the software development process, defining the majority of the software development and verification activities (see IEC 62304 Focuses on Five Software Processes). This process includes activities such as software development planning, requirement analysis, architectural design, software design, unit implementation and verification, software integration and integration testing, system testing, and finally software release.
This standard not only outlines requirements for each stage of the development lifecycle, but also takes care of the maintenance process, the impact of software change to the existing system, and the risk involved in implementing the software change. The standard also discusses in detail the effect of the SOUP items, including planning, requirement analysis, architectural design, maintenance, and risk management.
Legacy and SOUP software that can be reused in the development of new devices has become prevalent since medical devices now tend to be built on general-purpose embedded hardware. The use of SOUP in medical devices has its advantage in that the manufacturer can concentrate on the application software which needs to run device-specific functions.
SOUP is often developed for general-purpose applications, and using this general-purpose software in medical devices adds challenges. Most SOUP modules are provided by third-party vendors who may not follow any specific software process, software standards, or even document the code.
While SOUP addresses platform concerns, thereby saving programming time, it also brings with it a number of dangers. For example, projects are initially subjected to functional system testing which usually offers poor code coverage, leaving many code paths unexercised. When that code is applied in service, the different data and circumstances to which the code is then exposed are likely to use many such paths for the first time and hence unexpected results can occur.
The European System and Software Initiative “Performance of Errors through experience-driven Test” (PET) investigated this phenomenon and agreed that deployed code often possesses many errors. Their findings demonstrated that the number of bugs that can be found by newer methods of testing, such as static and dynamic analysis, is large, even if that code has been through functional system testing and subsequently been released.
1. Even code exercised both on site and by functional testing is likely to include many unproven execution paths. Code enhancements are prone to call into service combinations of data not previously encountered, resulting in the possibility of tapping into those previously unexercised paths.
The legacy software previously subjected to functional testing is then deployed for further tests. Even if it worked well, some part of the code may not be exercised, even when the product is in the field. When legacy code needs ongoing development for later revisions or new applications, previously unexercised code paths are likely to be called into use by combinations of data that were never previously encountered.
To counteract this potential weakness, a detailed structural coverage analysis needs to be undertaken to ensure that there is no unexercised code in the legacy software. IEC 62304 mandates functional coverage (i.e., ensuring the software functions per system design requirements) and structural coverage (i.e., all code sections are exercised and shown to work properly) of the legacy software along with a detailed analysis of the risk that could be introduced by the addition and use of such software.
It’s the device manufacturer’s responsibility to specify the functional and performance requirements of the SOUP items that are necessary as well as the system hardware and software needed to support the proper operation of the SOUP item. Any changes to the SOUP item need to be analyzed to determine whether the software modification could interfere with existing software and introduce new risks. As highlighted earlier, IEC 62304 addresses SOUP items during software planning, requirement management, architectural design, integration testing, system testing, risk management, maintenance, and change management phase.
Software planning calls for a detailed plan of the SOUP items to be used. This plan should define how these items are to be integrated within the existing system, how to manage the risk associated with the SOUP, and how software configuration and change management might affect the system. Requirement management plays a pivotal role in ensuring the medical device’s functional and performance requirements, including any SOUP items, are met and verified. Because many errors have been introduced in medical devices when new functionality is added, IEC 62304 extensively details how maintenance and change management must be done.
As you can see from our discussion so far, IEC 62304 outlines sound software development practise for medical devices from planning, requirement analysis, implementation and verification, integration, and software release. The standard ensures that the risks associated with third-party SOUP items are regulated at all stages of the software development lifecycle.
Industry regulators hope that, by implementing IEC 62304 safeguards, medical devices will receive the thorough functional and structural coverage analysis that leads to better software quality. With a more maintainable system, the SOUP items in medical devices will remain safe when exposed to later revisions.
Anil Kumar is a technical consultant with LDRA in India, specialising in the development, integration and certification of mission- and safety-critical systems. With a solid background in development tools and real-time operating systems, Anil guides organizations in selecting, integrating and supporting their real-time embedded systems from development through to certification.
Mark Pitchford has over 25 years’ experience in software development for engineering applications, the majority of which have involved the extension of existing code bases. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. For the past 10 years, he has specialised in software test and works throughout Europe and beyond as a Field Applications Engineer with LDRA.