RTC Magazine

The recent IEC 62304 standard for medical device software is causing companies worldwide to step back and examine their software development processes with considerable scrutiny. While software development and testing is still an integral part of overall system design and production, the IEC 62304 standard focuses on software as a separate lifecycle process with specific needs for risk management and safety assessment. 

With IEC 62304, the world has changed, literally—country by country—for medical device manufacturers. This doesn’t mean, however, that complying with IEC 62304 must slow down your medical device software development.  By applying best practices guidance and process automation, companies have a new opportunity to improve on their fundamental business goals, while getting through regulatory approvals faster.

Changes in the Medical Device Field

The IEC 62304 standard points to the more powerful role that software plays in the medical device industry. Once hardware was king. Older systems used software, of course, but it wasn’t the focus, Software was primarily used for algorithmic work. Not to overly generalize, but the focus of management was on building hardware that worked correctly; software was just a necessary element of overall implementation. Now with complex UIs, easy-to-use at-home medical devices and systems, etc., software has taken on a much more vital role. 

Today, software is where the consumer value lies in systems engineering, and embedded software is creating opportunities for competitive differentiation. Thus, software developers are beginning to play a greater role in the design, architecture and functionality of medical devices. Tried and true software development methods are also being woven into the overall product engineering process. These methods must recognize that changes occur to requirements over the course of the lifecycle, and be able to adopt the appropriate levels of flexibility in order to cope. 

Rapid changes in supply chains and changes in requirements mid-stream during a given product delivery cycle are causing some degree of chaos for engineering teams, including the software development teams. Now, the IEC 62304 standard requires traceability in the software delivery process (the ability to ensure that requirements map to each element in the software process). But as software teams working in this bold new world seek to adopt agile techniques to better meet deadlines and expectations, they are struggling to embrace the demand for traceability, which is simply not the “sweet spot” for agile development. So the question is, how do we introduce more rigor to the development process, and meet the needs of this new industry standard?

The Hard Part Is Software

Coordinating people, processes and tools is never easy. So why does a greater role for the software component make the effort even harder? 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. 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 can be highly subjective. 

Agile and iterative delivery methods, which enforce frequent stakeholder review of the working software under development, help guide software projects toward more satisfactory outcomes. But, as noted earlier, 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 need to be scaled up with additional guidance from configuration and requirements management practices, at minimum. Modeling your architecture is another great way to scale up your process to meet the requirements expected of IEC 62304.

The IBM Rational organization has recently provided some clear guidelines for scaling agile methods for larger, more disciplined software development activity. Called “Disciplined Agile Delivery,” the new guidelines provide teams of any size many of the benefits of traditional methodologies while retaining the results-oriented spirit of agile development. Of course, it will not always be the case that a development team working on the software components for a medical device will be a large team, but the traceability required by the IEC 62304 standard demands more than a purely agile approach, and Disciplined Agile Delivery (DAD) offers a solution. DAD is itself a very big topic. Suffice it to say that the overall quality management concerns introduced by the new IEC 62304 standard are addressed by DAD. 

The Specification Details

The history of standards for systems manufacturers provides some context for the IEC 62304 standard. Figure 1 shows the relationship of prior product engineering standards that impact the design and implementation of medical device software. The emergence of IEC 62304 is big news, in part, because it requires systems teams to manage this larger environment of industry requirements around a clearer understanding of software as the “brains” of the system.  

Let’s consider what the software team manages as the software evolves not only to meet design specifications, but also this large complement of regulatory compliance mandates. For starters, the IEC 62304 standard demands additional rigor around traceability, reporting, architecture and requirements management. What follows isn’t a comprehensive list, but it covers several of the essential guidelines and how they affect software delivery teams. 

IEC 62304 states that requirements analysis must be part of the software development process. The requirements analysis discipline establishes the high-level requirements of the system being designed, and derives lower-level requirements from those until the process produces requirements with sufficient information to enable coding. These lower-level requirements detail the complete system, including potential faults and interfaces between systems. These can be developed iteratively in an agile process, but the IEC 62304 standard demands that they must be documented.  

Requirements also need to link to other phases of the process, including the software architecture, test cases and so forth. The general idea is that someone can look at a requirement and understand what should be implemented and what tests must be performed to prove the requirements are met. Requirements typically are written by systems engineers as simple text early in the design process as they capture ideas on paper.

Another discipline required by an IEC 62304 guided process is architectural design. This turns the requirements into a coherent architecture so developers can understand how the requirement will be met and ensure there aren’t any overlaps or holes in the requirements as described. Graphical images often are used to help development teams visualize an architecture emerging from the requirements. The graphics should map to the actual code, which provides the means for traceability from requirements all the way to the code.

A key part of the overall process is failure mode and effect analysis (FMEA). FMEA is a powerful tool for explaining the potential failures to a regulatory agency. It shows how the identified failure points map to the requirements and the tests that need to be run in order to prove that the failure can be handled correctly. Fault Tree Analysis (FTA) is a graphical way to help analyze the system to see where a failure is likely to occur. Typically used during the early analysis phase of development, FTA diagrams show how failures interrelate. FTA diagrams combined with FMEA create a comprehensive strategy for identifying, understanding and tracking potential failures.

Another important discipline is testing: The IEC 62304 standard discusses both integration and system testing. Integration testing ensures that different components actually work together and do not cause unanticipated behaviors. System testing treats the whole system like a black box and ensures that high-level requirements are met by the system itself. Each testing discipline is critical for meeting the requirements of IEC 62304. They also are quite useful for ensuring your device works as expected.

While developing reports isn’t specifically listed as an IEC 62304 requirement, in the end a report is what needs to be sent to the regulatory agencies. That report needs to include all the information listed above and explain how they trace between each other to make a comprehensive whole software system for the medical device.

Getting to IEC 62304 Compliance

The needs described above are met through software development tools specifically geared for systems delivery, which is often divided into multiple categories: systems engineering, project management, software engineering and test management, for example. These categories ideally interconnect across the systems delivery lifecycle in performing distinct tasks and creating distinct lifecycle work products. 

Typically, hardware and software teams today use similar processes for development. The standard V diagram in Figure 2 shows the typical stages both teams use for analysis, design, implementation and testing. The challenge is that the teams operate separately, limiting their ability to synchronize key steps. What’s more, alignment is hindered by the use of different languages and tools. To achieve rapid code development and the associated business benefits, the hardware and software processes need to be integrated into a unified process.

This general, ideal process illustrated in Figure 2 provides a kind of map for software and systems development teams to address the needs of a standard such as IEC 62304. Some of this process may be part of your current methods; some portions may be clearly missing; and some may be unclear. The next step is to go about your own gap analysis to determine where you need to improve to meet the standard.

Performing a Gap Analysis 

IEC 62304 compliance does not need to slow down your medical device software development. But we DO recommend that you perform a gap analysis to see how closely your own process maps to the specifications of IEC 62304. You may eventually hire a third party to help you come into compliance with the new standard, but you should do the gap analysis first, just to take an inventory of your process and its typical artifacts. You may find that your documented process isn’t the one you actually follow in practice.  

Get started by examining your process on paper. Is this process truly the one you are following?  Be honest with yourself, and determine if your departures from the stated process occur across all products, or only some. Try to determine where your software tools are most helpful—where the integrations are strong and consistent across the entire organization; and identify the areas for improvement. 

For example, do you have the traceability between the phases as required by the new spec? Some organizations conduct traceability only on paper. Requirements are linked to specific locations in the code, but requirements described early in a project can become out of synch with the actual code because, as discussed earlier, requirements evolve as development goes on. Hence, you need a requirements management method that maintains a link to the actual code that addresses each requirement, not simply a line number or some other meta reference. 

Of course, it is up to your organization to decide what works best for you, and changes should be carefully considered both in light of the IEC 62304 specification as well as your product delivery culture and history of success. The best tool solutions will be those that allow incremental adoption of new capabilities, allowing you to avoid wholesale process changes and massive new infrastructure investments.  

A developer immersed in the details of code she has just written may have a very clear sense of how that code addresses a specific requirement. But even brilliant code that is not well documented won’t meet the specifications of IEC 62304, since a new level of traceability between requirements and code is now demanded. Yet, your brightest developers may detest the need to demonstrate this traceability, since it has little to do with the ingenuity they have brought to bear on their various coding assignments. That’s why it is vital for your tools themselves to show these connections. You not only alleviate the bother of manual reporting, but the best tools can also dramatically reduce the possibility of human error that invariably is part of a manual process. 

IBM
Armonk, NY. 
(914) 499-1900. 
[www.ibm.com].