Features

The IEC 62304 standard for medical device software is causing system engineers worldwide to step back and examine their software development methods with considerable scrutiny. Although at one time, software development and testing was an integral part of overall system design and production, the IEC 62304 standard focuses on software as a separate lifecycle process that requires strong support for risk management and safety assessment. This does not mean, however, that complying with IEC 62304 should necessarily slow down the medical device software development process. By applying best practices guidance and process automation, medical device companies can reap the benefits of getting through regulatory approvals faster, lowering costs, and delivering safer devices.

The Bright Side of the IEC 62304 Standard

The IEC 62304 standard may even present manufacturers with an opportunity to hone their competitive edge. As with smartphones, automobiles, and other embedded devices, software component is an increasingly critical component in today’s medical devices, and it is driving much of the innovation that distinguishes one company’s products from another’s. Envisioning and delivering differentiation through software is helping savvy medical device companies penetrate new markets and outshine the competition.

For some businesses, IEC 62304 compliance may serve to jump-start greater competitive strengths based on software. For companies with mature software capability already in place, compliance will be a trivial matter. Whether their current software development and delivery capabilities are based on traditional, iterative, or agile practices, the IEC 62304 standard allows organizations to retain their existing processes. However, some may need to add capabilities to instantiate a more robust software delivery process — one that not only affords good quality and risk management, but also prioritizes established software development best practices. This includes software configuration management, with traceability of requirements and artifacts among the various processes in place.

All of these processes are vital for dependable software development and delivery — and that’s equally true for software engineers in IT as well as any number of embedded device markets. But coordinating people, processes, and tools is never easy.

The primary difficulty has to do with the nature of software itself. While the best thing about software is that it is soft (i.e., relatively easy to change), this is also its riskiest attribute. Unlike bridge construction, most software does not deal with natural phenomena where laws of physics or materials provide a widely understandable framework. Instead, most software is constrained only by human imagination; the quality of software is judged not by precise mathematics and physical tolerances, but by the degree to which it satisfies a user’s expectations, which is highly subjective.

For these reasons, agile and iterative delivery methods enforce frequent stakeholder review of the working software under development, which helps guide software projects toward more satisfactory outcomes. But software practitioners following the more “pure agile” methods — such as Scrum or XP — may find that the new emphasis on requirements in IEC 62304 demands a more formal, less “agile-feeling” lifecycle. Pure agile methods will need to be scaled up with additional guidance from configuration and requirements management practices, at the minimum. Modeling your architecture is another great way to scale up the process to the requirements expected of IEC 62304.

The good news is that this standard doesn’t require any one specific software development and delivery process. A company can choose to use its traditional “waterfall” methods if preferred; it can use the Unified Process (UP) or one of its flavors, such as IBM’s Rational Unified Process (RUP), or tailor its agile development practices to conform to IEC 62304 requirements.

A Worldwide Standard

With IEC 62304, the marketplace has changed for medical device manufacturers. A number of years ago, the U.S. Food and Drug Administration (FDA) was the gold standard for medical device scrutiny and assurance. Once businesses received FDA approval for their devices, that usually meant the rest of the world approved as well. However, over the course of time, the EU and Asia-Pacific countries developed their own stricter standards, and manufacturers could no longer count on FDA approval as a green light for multinational distribution of products.

Today, medical devices must pass through all countries’ regulatory agencies individually. Add to that consumer demands for ever-higher software performance, as noted earlier, and device approval has become an increasingly complex proposition.

Yet again, there’s a silver lining here: Because the standard has been adopted worldwide, a company may find an easier route to market for new devices, since most countries have established this as the standard for their software development regulatory needs. While approval in all countries is still required, at least the countries are asking companies to meet the same standard, which offers companies a framework for meeting software requirements in all countries without having to satisfy individual regulations.

Next Steps for Medical Device Manufacturers

IEC 62304 compliance does not need to slow down medical device software development. However, companies should perform a gap analysis to see how closely their own process maps to the specifications of IEC 62304. They may eventually hire a third party to help comply with the new standard, but it is advisable to do the gap analysis first, just to take an inventory of the process and its typical artifacts. Sometimes companies may find that their documented process isn’t the one they actually follow in practice.

« Start Prev 1 2 Next End»