Medical device developers need help navigating the FUD of OS vendors' "mission critical" claims
January 16, 2015
In a previous life, I built four medical companies and took two of them public (confession: I did personally destroy one and sold out another before I...
In a previous life, I built four medical companies and took two of them public (confession: I did personally destroy one and sold out another before I could ruin it; not a bad record). I was also a principal investigator for several National Institutes of Health (NIH) medical research programs. Hence, at least as a historian, I have experience that I’m glad to share with the industry.
From 1969 to 1985, I brought some 20 medical products to market through the FDA’s (now CDRH) 510k premarket approval process (the FDA doesn’t approve any medical device, but approves compliance with the Medical Device Act Section 510k). I might mention that the FDA Premarket Requirements began with the Medical Devices Act of 1976. It was necessary to gain compliance with the act for any medical device to be marketed. Devices brought to market before the Medical Devices Act were grandfathered. Interestingly, one of the required aspects of the Act was to show “essential similarity” to previously marketed devices; namely, those that were already in use.
It continues to astound me that very smart techies/vendors in our embedded marketplace continue to assert that medial devices, particularly patient monitoring devices, constitute “mission critical” developments and thereby demand mission critical OSs. Of course, this is bullfeathers and I’ve previously published the facts of why this idea is false in the paper, “Helping Medical Device Developers to Navigate Through the FUD that Pervades OS Vendor Claims of ‘Mission Critical’ Requirements.”
When I dealt with the FDA back in the mid 70s, they had only 11 weeks to respond to the 510k filing. Otherwise, 510k compliance was automatic and valid without FDA certification. The FDA Medical Device Section handled this restriction by denying most applications, necessitating refilling under appeal. Today this rule is no longer valid and such applications can take up to 24 months.
So it is important to get it right the first time. After a software recall, the CDRH may require a re-filing that can take an additional 24 months.
This sometimes seemed ridiculous. For example, I brought a pediatric anesthesia mask to market that had a detachable “binky.” The pacifier was useful in holding down the tongue during anesthetic induction (wherein the muscles relaxed obstructing the airway) and after surgery it was detached and used as a pacifier. Data showed that infants that suckled have higher oxygen partial pressure (PO2) levels than those that didn’t.
The FDA rejected our initial application, claiming that “while the mask and the pacifier are safe when used separately, the combination constitutes a lethal risk.” After threatening to go to our U.S. Senator, the FDA did rethink their prior claim.
I wrote a paper, “Critical Issues Confronting Medical Device Manufacturers,” that points out the difference between the 510k premarket application and the need to delve deeper in documenting the software design so that in the event of a necessary product recall, an audit path is available to the CDRH forensics group (a potentially difficult group to deal with, as it should be). If handled correctly, the forensics group may allow a faster path for 510k recertification.
Let’s address whether mission-critical software is required for patient-monitoring applications. Typical monitored parameters include heart rate, respiratory rate, and sometimes blood pressure and percutaneous PO2. Most patient monitoring consists of heart and respiratory rate. Physiological displays consist of ECG, pulse, and respiratory wave forms. Developers should consider the following:
- The ECG waveform has a frequency response of 100 Hz
- The pulse waveform’s duration is between 200 and 450 ms
- Respirator rate is between 6 and 20 per minute
Prior to 1980, heart rate was measured almost exclusively using the ECG waveform, which is separate from cardiac contraction. One can have a perfect ECG waveform during a cardiac arrest. Hence, heart rate is currently measured by pulse pressure generated from actual cardiac contraction. However, when you look at the physiological display panel, you see the ECG waveform as well as the pulse pressure. It’s merely for historical reasons. Hundreds of billions of ECG waveforms have been gathered since 1900 and the reference to ECG is a part of medical culture.
So why did mission-critical OS vendors hopelessly invest millions of dollars trying to convert developers to their products? I have my theories (see “The Concorde Fallacy”), but you may have your own.
Truth be told, developers ONLY need to embody a fail-safe ALARM system to insure patient safety.
Jerry Krasner, Ph.D., MBA is Vice President of Embedded Market Forecasters and its parent company, American Technology International. A recognized authority with more than 30 years of embedded industry experience, Dr. Krasner has extensive clinical research and medical industrial experience, including the successful filing of more than twenty 510k submissions. He earned BSEE and MSEE degrees from Washington University, a Ph.D. in Medical Physiology/Biophysics from Boston University, and an MBA from Nichols College. He has been a visiting professor at the Universidad de Las Palmas (Spain) where he was recognized for his work in neurosciences and computer technology.