Jerry Krasner, Ph.D., MBA
How to develop better products, save money, meet FDA/CDRH requirements more efficiently, and avoid recalls, lawsuits and nasty criminal complaints that can put you in jail
Introduction:
As a matter of full disclosure—and at the risk of appearing anachronistic—I am a veteran of the old FDA medical device wars and have the scars (and bank account) to prove it. Looking at today’s efforts of medical device vendors to “capture” market share using their current products—most of which are inappropriate to the needs of the medical device marketplace—it provides for a sense of, as Yogi Berra once put it, “Déjà vu all over again.”
During the approximate period of 1967 to 1986 (gosh that really dates me), I brought many products to market having achieved FDA notification of compliance under Section 510k of the Medical Devices Act of 1976 (since amended in 1990 and 1997). In those days the FDA, now called the CDRH (Center for Devices and Radiologic Health), had a scant 11 weeks to respond to a 510k application or the application was automatically accorded. (Today the 510k process can take up to 2 years.) Perhaps this is why I had so many frustrating—if not ridiculous—encounters with the FDA’s Medical Device Center.
Citing just one of more than a dozen examples, I brought to market a pediatric anesthesia mask that had a detachable pacifier. We were also able to provide a fragrance that kids loved, and it made the task of the anesthesiologist a lot easier as kids picked out their mask fragrance before entering the hospital (Tutti-Frutti Bubble Gum was the overwhelming favorite). We provided documentation that showed that the pacifier held down the kid’s tongue thereby avoiding airway obstruction during the introduction of anesthesia. In addition we showed that having the patient suckle on the pacifier (when it was detached from the mask following anesthesia) provided enhanced post operative oxygenation.
The examiner ruled the combination of the mask and pacifier a “potentially lethal weapon”! This was, of course, ridiculous. We finally got the 510k compliance notification but it took 4 months.
Truth be told, I have not filed a 510k in more than 20 years and I trust that the CDRH now hires only the best from the industry. So what is it that this old-timer might offer the developers of medical devices, the executives that might run a felony risk if their company delivers a product that kills someone, as well as the embedded technology vendors that wish to increase their market share and ameliorate the coming tsunami resulting from significant decreases in discretionary DoD funding?
Risk at the Top – How Pending Legislation Might Put Your CEO in Jail
On July 31, 2008 a Senate Bill cosponsored by Senators Edward Kennedy (D – MA) and Chuck Grassley (R- IA) was filed that would require senior officers or directors of drug and medical device companies to certify under penalty of perjury that all information submitted for a product’s approval is accurate and in compliance with federal regulations.
The Drug and Medical Device Accountability Act Bill expired at the end of the two-year Senate session on December 31, 2008, but was refiled in the Senate in 2009. This is an important piece of legislation, and medical device executives should get their house in order to accommodate the provisions.
The bill provided that product applications later found to have contained false or misleading information would be subject to stiff fines (up to $5,000,000), assessed both to companies and their senior officers, who, in addition, could face jail sentences of up to 20 years. These are serious issues. Currently the CDRH has a forensic group that looks at device software only after a device has been recalled.
If enacted, the “2009 Drug and Medical Device Accountability Act” will change the medical devices industry similarly to how the Sarbanes-Oxley bill impacted corporate accountability. Laws being what they are, we should expect overkill from its enactment. This is why medical device companies’ senior management should take time to rethink their strategic approach to the delivery of their products. The bill has apparently been put on hold since Kennedy’s death, but it might be resurrected.
The FDA’s Center for Devices and Radiological Health (CDRH) reports that in 2006, 21% of all medical device recalls were for software defects—it is also estimated that one in three software-based products is recalled. They haven’t updated this data since, but one can assume that it might have gotten worse.
What’s a Medical Device Company to Do?
Strategically, the best approach that a medical device company can take is to utilize the best technology that the industry has to offer—an approach that includes:
- Requirements Definition and Management
- Change and Configuration Management
- Quality Management/Testing—Software Verification and Validation Tools
- Modeling
- Release Management
- Documentation
- Team Collaboration
Following this strategy, the ability to develop and implement a software development internal audit path to provide assurance and confidence in the integrity of the software is clearly a “best practice.” For example, using UML code reuse modeling technology, the developed software can be retained and used for future upgrades. Also, this audit trail can be used in the event of a product failure to show the CDRH forensic group that all due care was taken in the product’s development and deployment.
Do I Really Need a DO 178B Certified OS?
Don’t get caught up with industry hype for highly certified RTOSs (e.g., DO 178B Level A certification). It is a good design practice to use an OS that is specifically suited for your application. ThreadX, Micrium and Nucleus (as well as MontaVista Linux) are examples of OSs that are currently deployed in hundreds of millions of applications. Remember that for patient monitoring applications the expected critical frequency is 100 Hz—so the use of a costly OS that guarantees a 10 microsecond response is unreasonable, expensive and power hungry. Base the selection of the OS and the processor on the systems requirements. If you need secure communications, you can run your existing applications on a MILS-certified OS as a guest OS and not have to worry about rewriting existing code.
What Guidance Has the CDRH Provided That Would Help Us?
On May 11, 2005 the CDRH issued a non-binding “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.” Given the potential consequences of improper filings contained in the Drug and Device Accountability Act of 2009, it would constitute a best practice for any CEO to embrace the guidance provided by the CDRH.
Although the following is not required as part of the 510k filing, it makes good sense to follow these guidelines as an internal “Best Practice.”
1) Risk assessment and management is a very important part of your filing with the CDRH and can be your best approach for protecting you under the Act. Be exceedingly careful in documenting the “Level of Concern” section of your application. It would be wise to include systems failure documentation that is available through modeling or formal methods for certification. Make sure that you specify the correct level of concern and document your approach to rectifying potential failures.
2) Develop a Device Hazard Analysis for all software devices—include all hazards (hardware and software) associated with the product’s intended use. This can include the user GUI and how it might be operated by personnel that work under stressful conditions.
3) Develop a Software Requirements Specification (SRS) that includes functional, performance, interface and developmental requirements for the software, including hardware, OS and programming language requirements.
4) Develop an Architecture Design Chart (flowchart or similar illustration) that describes the relationships among the major functional units in the software device. There should be sufficient information to allow for the organization of the software relative to the functionality and intended use of the software device.
5) The software design specification should present information to demonstrate that the work performed by the software development engineers was clear and unambiguous, with minimum ad hoc design decisions. Use a requirements management tool such as DOORS—rather than depend on Word.
6) In a perfect world, you should be able to relate requirements with code. It’s a good idea to show the relationship between requirements, code and testing. Doing this visually (through modeling) makes the most sense as it is easier to visualize the code executing.
7) Develop a summary of the Life Cycle plan and the Life Cycle processes employed. It will be useful to develop an annotated list of the control/baseline documents generated during the software development process, and a list or description of software coding standards.
8) Develop verification and validation documentation and base it on the claimed Level of Concern. Whenever software is changed, a validation analysis should be conducted to validate the specific change and also to determine the extent to which this change may impact the entire system’s operation. Documentation and tracking is essential.
9) Include a revision level history of software revisions generated during the course of product development.
Following these guidelines will minimize product failures due to software malfunction and provide an audit trail for the CDRH forensics group in the event of a product failure, to show that all due diligence was followed.
About the Author:
Jerry Krasner, Ph.D., MBA is the founder of Embedded Market Forecasters and its parent company, American Technology International (1991). A recognized authority with over 30 years of embedded industry experience, Dr. Krasner has extensive clinical research and medical industrial experience, including the successful filing of more than a dozen 510k submissions.
Dr. Krasner served as President of Biocybernetics, Inc. and CLINCO, Inc., Executive Vice President of Plasmedics, Inc. and Clinical Development Corporation, and Director of Medical Sciences for the Carnegie-Mellon Institute of Research. He has been the principal investigator of several NIH funded clinical research programs.
Dr. Krasner was formerly Chairman of Biomedical Engineering at Boston University, and Chairman of Electrical and Computer Engineering at Wentworth Institute of Technology.
Dr. Krasner earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology / Biophysics from Boston University and an MBA from Nichols College.
His papers can be seen at www.embeddedforecast.com and on his Blog www.embeddedmarketintelligence.com.
