Easing IEC 62304 certification for medical devices

(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 recognized 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 practice 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 medical-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 software development lifecycle

   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, which this article examines, along with the software development lifecyle.

   Click to read "Easing IEC 62304 certification for medical devices," which originally appeared at our sibling publication Medical Electronics Design.

About the authors

Anil Kumar is a technical consultant with LDRA in India, specializing 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 specialized in software test and works throughout Europe and beyond as a Field Applications Engineer with LDRA.

Editor's note: Liked this? Want more?

If you are interested in "medical-design" issues including transducers and interfaces; processors; software; and system design, then go to the Medical Designline home page for the latest in design, technology, trends, products, and news. Also, sign up for our weekly Medical Designline Newsletter.