Managing Software Risk

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI September 1997 Column

To the Editor:

The June 1997 cover story, "Software Risk Management: Not Just for the Big Manufacturers?" by John Suzuki and Dale W. Karolak, was excellent, but the authors made one potentially misleading claim. Their assertion that their methodology meets the requirements of FDA's September 1996 510(k) draft guidance on software risk management is not true, because the methodology does not rigorously address safety risks.

The article states that the methodology will identify risk in technical, cost, and scheduling areas. But FDA is solely concerned about risk in another area: safety. Perhaps the authors assume that once technical risks are addressed, the safety of the software will be established. But their methodology does not include anything so rigorous as failure mode and effects analysis, and that omission invalidates their claims about satisfying FDA's draft guidance on software risk management.

Brian Palmer
Systems Analyst
COBE Cardiovascular, Inc.
Arvada, CO

John Suzuki replies:

The purpose of our article was to provide a simple tool for developers to use while performing software risk management from an overall process standpoint, not from a product standpoint. In our original unedited draft, we mentioned the required FDA approaches to product risk such as failure mode and effects analysis (FMEA), fault-tree analysis (FTA), and hazard analysis. But we chose not to focus on these areas because of length limitations and referred readers to several helpful references on those topics. These topics have also been addressed in previous MD&DI articles. Unfortunately, also because of space considerations, these references were cut.

In the second to the last paragraph of the article we stated that "SERIM [Software Engineering Risk Model] can also help users satisfy FDA and IEC requirements for risk management." We never stated that using the method alone would satisfy those requirements, although I can see how a casual reader may reach that conclusion. Manufacturers must read and study the FDA 510(k) software draft and the IEC 601-1-4 standard to ensure that all sections of these documents are addressed properly.

Because of length restrictions, we did not discuss the tailorability and flexibility of the model and methodology. We focused specifically on giving the reader the essential elements to perform only the basic process.

What is not stated in the article is that in my own work I use a model that includes the additional risk factor of safety for both product and process to make the model more practical. Several risk factor sections, which are listed on page 74 of the article, contain questions that specifically relate to medical device software development for safety-critical applications. For instance, the risk factor of development methodology lists a set of specific questions that deal with the use or nonuse of specific software risk hazard methods such as FMEA and FTA. The weight of these questions is much greater than that of other questions in the model. Under the risk factor of correctness, I included questions that ask whether traceability of the requirements, detailed design, code, and test cases have been or will be performed during development.

Another question that can be added to the model is, "Has the developer estimated the likelihood and severity of software risks and provided means to mitigate and control those risks?"

Essentially, all key requirements of FDA's draft guidance and IEC's 601-1-4 can be incorporated into the model because it will handle both a product and process view of risk. The questions and model can also be tailored to the level of concern for the device. I am currently working on an expanded model to handle all 510(k) and IEC 601-1-4 requirements.

Copyright ©1997 Medical Device & Diagnostic Industry