The Risk Factor

In my opinion, it was unconscionable for SCOTUS to have indemnified the manufacturers of Class III medical devices that have received FDA approval. If we could sue the FDA when one of these devices proves faulty in design or implementation, then that would be another thing, but the fact is that the FDA gives what appears to me to be at best a cursory look at these devices. They certainly do not perform as thorough and comprehensive a failure-mode analysis on these devices as they should, and innocent people suffer (and possibly die) as a result.

As for software failures, with almost 30 years experience in the design and development of highly complex real-time systems, I can attest that there are more modes of failure in these systems than can possibly be tested or analyzed for, and given the existing pressures related to time-to-market and cost-reduction that are placed upon the engineers who are responsible for these systems, it is understandable when "stuff" happens... Just remember the Therac disaster, and that system was orders of magnitude simpler than some of the ones we are seeing today.

If Class III device manufacturers are really immune from lawsuits, that does seem problematic. The courts have allowed tort cases that seem frivous to me (e.g., the MacDonald's coffee suit), but a dangerous medical device with rare and unknown failure modes seem to be a different breed of cat. Software can't be completely tested, of course, so there is always some risk. The same is true of adverse reactions to drugs and drug manufacturers can be sued. I don't see the difference between the two, and the disclosure is far greater with drugs than with devices. That also seems to me to be part of the risk since software likely contains unknown and may contain unknowable failure modes. We have to accept some risk with every medical treatment, and this is true of every technology. It seems reasonable that there should be limits to liability for medical device makers, but the courts should be following the example of the construction industry. Every building is designed by a PE and built according to code. When structures fail, the courts determine if there is negligence involved to determine where liability lies. It seems to me that the same principle applies to medical devices.

I agree with William Boyle. I spent most of my career developing real-time devices with program control, and just identifying the worst case design points to test is a major effort.
However, beyond that, since when does a design evaluation of any technology assure that no faulty manufacture or component failure won't create a dangerous situation?

There is a misconception about the difficulty in verifying software systems (or any system for that matter) - that the difficulty is worse than polynomial effort as a function of system size. For a substantial class of well designed systems, this is not the case. Linger, Mills, and Witt in "Structured Programming Theory and Practice", 1979, use the structure theorem (p. 118) to show that any "proper program" can be factored using a functional basis {sequence, case, loop} with effort O(n log n). As in the Cleanroom Process (http://en.wikipedia.org/wiki/Cleanroom_Software_Engineering), such a factoring can then be subject to rigorous proof and testing with effort O(n). Of course, not all systems consist entirely of "proper programs", but many systems can be designed using OOA&D to localize the non-proper parts into managably small classes thus substantially localizing and focusing the verification risk. For this purpose, the structure theorem is not a design method, but is used post-design (or co-design) to create a rigorous verification of the design. The overall effort scales as O(n log n). This is achievable with real teams and real budgets provided there quality imperatives are applied to the relevant development organizations (quality becomes a requirement that cannot be traded away for, e.g., time to market, design cost, etc.).

Once the verification is under way (including formal inspection of requirements, design, and code), it is possible to estimate residual defect loads for operationally approved scenarios using multiple independent means: process agnostic Rayleigh curve fits to whole project defect data, statistical process control analysis of inspection data, and statistical analysis of individual inspector defect detection rates (capture-recapture model). For the cost effectiveness of this analysis, see my Crosstalk Articles:

How Much Code Inspection is Enough?: http://www.stsc.hill.af.mil/crosstalk/2001/07/mccann.html

When is it Cost Effective to use Formal Software Inspections?: http://www.stsc.hill.af.mil/Crosstalk/2004/03/0403mccann.pdf (answer, nearly always, even multiple inspections will pay dividends, especially in security evaluation)

The Relative Cost of Interchanging, Adding, or Dropping Quality Practices - http://www.stsc.hill.af.mil/Crosstalk/2007/06/0706McCann.html

I am currently preparing an IEEE Readynote detailing the residual defect estimation analysis methodology.

The state space of the compiled program can then be fully explored with Mr. Linger's Function Extraction tools that he and his team are designing at the CERT laboratory of the Software Engineeing Institute: http://csdl2.computer.org/comp/proceedings/hase/2004/2094/00/20940267.pdf

I also agree with William Boyle. While it has been a few years since I was head of QC for a medical device manufacturer, one of the things I was told in an FDA seminar was that basically whoever signs off on a product for release may be held individually responsible for faults that occur. This is in addition to the company itself. It was brought out that the head of QA/QC was especially liable. Of course, there were limits as to what constituted due diligence, so there was a reasonable amount of protection.

While I won't say that this made me more diligent in the pursuance of my job, I will say that it made Management more willing to fund extensive testing and allow veto rights on any release that did not measure up. With the removal of financial liability, I am not sure the market will allow this level of Management support for QA/QC to continue.

As Terry Grant notes, specific programming techniques can mitigate verification and validation problems in complex software systems. Based on my experience as a consulting designer on large-scale medical informatics projects, I would add certain development methods and practices, particularly test-first development and pair programming, both of which have proved effective at reducing the so-called defect injection rate (the rate at which bugs get into the code in the first place) and consequently the residual defects in delivered software. Such practices are best combined with disciplined model-driven design and systematic requirements engineering, which, unfortunately, requires a level of maturity from software developers lacking in many organizations and all too many professionals.

WRT Bob McCann's post, three of the four links presented refused to open when I tried them. Perhaps this is a good metaphor for the problematic nature of software verifiability?

Not all Class III medical devices are immune to lawsuits.

Also I would like to point out that typically the FDA would only go after senior management since the latter is supposed to have a quality system feeding them the right information at the right intervals (e.g. management reviews). Now senior management is also known to delegate many tasks downstream but this is one thing that they cannot delegate: liability. Yes, senior management can terminate the software person(s) who wrote the faulty line(s) of code or did not test the code well but the FDA will not come after the coders/testers. Too often, senior management bonuses are linked to production quotas. Now how likely will these people stop production for quality issues?

I guarantee you that the indemnity in other areas has already made medical manufacturers very sloppy. I've worked in high reliability design my entire career and I've never seen such shoddy design verification for life-critical implantable defibrillators or pacemakers as when I worked at Medtronic.

It appears that nobody, including the original poster, actually read the Supreme Court's ruling. It essentially denies liability claims under state statutes. This is based on the "preemption" granted in the 1976 Medical Devices Amendments. Claims can still be brought in Federal court, but the bar to prove liability is much higher. Also, the actual case was, to me, frivolous. According to the opinion:

"Charles Riegel underwent coronary angioplasty in 1996, shortly after suffering a myocardial infarction. His right coronary artery was diffusely diseased and heavily calcified. Riegel’s doctor inserted the Evergreen Balloon Catheter into his patient’s coronary artery in an attempt to dilate the artery, although the device’s labeling stated that use was contraindicated for patients with diffuse or calcified stenoses. The label also warned that the catheter should not be inflated beyond its rated burst pressure of eight atmospheres. Riegel’s doctor inflated the catheter five times, to a pressure of 10 atmospheres; on its fifth inflation, the catheter ruptured."

Seems to me that the doctor is at fault, not the manufacturer.

There is nothing in the ruling that "indemnifies" manufacturers of medical devices. You simply can't sue them in state court.

Wood makes a valid point – the bar is raised much higher for those injured from medical devices. However, the point still stands – the US Supreme Court has made manufacturers essentially immune from lawsuits for Class III medical devices once the FDA has approved them for use.

As I understand it, medical device manufacturers are now immune from liability and prosecution under State or common law for personal injury claims if the device was approved by the FDA prior to its being marketed and the device meets FDA specifications for manufacture labeling, including safety and efficacy.

Further, as I understand it (http://www.liebertonline.com/doi/abs/10.1089/pho.2008.9975), “Current federal law has no provision for damage suits against device manufacturers,” which is why people sued in state courts. That avenue is now cut off.

Can you still sue?

Sure, but now, as pointed out in this NY Times article, (http://www.nytimes.com/2008/02/22/business/22device.html), “As things stand now, lawyers expect injury lawsuits to leave design questions behind and focus on whether patients were harmed because a company did not make or handle the product according to the safety processes laid out in the documents approved by the F.D.A.”

“As sure as night follows day, every plaintiff is going to argue manufacturing defects,” Mr. Herrmann said. “That is the next battleground.”

“Another question may be whether injury lawsuits are barred in cases where manufacturers deceived the regulators by providing false data or withholding data on safety and effectiveness to get their marketing approval.”

But as the Times article further notes, “But Riegel may lead many judges to dismiss claims before plaintiffs’ lawyers can gain access to company production data, e-mail and other records through the pretrial process known as discovery. “It takes discovery to prove violations of the federal regulations,” said Neil Overholtz, a lawyer in Pensacola, Fla., who represents patients in device litigation.”

The Court's ruling has shifted the onus to the FDA to manage the people's risk extremely well in regard to these devices, since one avenue of relief is now denied.

As one can read here (http://www.malawyersweekly.com/index.cfm/archive/view/id/443150) the Supreme Court ruling seems inconsistent with its ruling in the past. This ruling isn't a minor issue, which is why Democratic leaders are vowing to make a legislative change to overcome the Supreme Court Ruling (http://www.nytimes.com/2008/02/21/washington/21device.html?ex=1361250000&en
=cf960715c4314072&ei=5124&partner=permalink&exprod=permalink)

Actually, anyone upset about this should probably take it up with Congress and President Ford, not the Supreme Court (which affirmed a lower court ruling 8-1). The preemption provision is part of the 1976 MDA law:

“Except as provided in subsection (b) of this section, no State or political subdivision of a State may establish or continue in effect with respect to a device intended for human use any requirement—
“(1) which is different from, or in addition to, any requirement applicable under this chapter to the device, and
“(2) which relates to the safety or effectiveness of the device or to any other matter included in a requirement applicable to the device under this chapter.” §360k(a).

The exception in subsection (b) allows the FDA to exempt some state and local requirements from preemption.

The Court referenced two other decisions, one in 1992 and one in 2005 where they held that "a provision preempting state “requirements” pre-empted common-law duties." So this should not be a big surprise to anyone.

Also, the decision in Lohr (which is what the malawyersweekly.com article says is inconsistent with this latest ruling) was for a device that grandfathered in by the MDA (what the article refers to as the "Gaping loophole"), not one that actually went through the FDA approval process for a Class III device, which the catheter in this newer case did go through. The court didn't reverse Lohr and went to great pains to note that they didn't (referencing Lohr 31 times in the ruling), but instead created two separate paths for litigation: one for devices that have not gone through full FDA approval and are therefore still subject to state and local laws, and those that did go through FDA approval and are not subject to those laws. (This is discussed in the liebertonline.com article.)

The malawyersweekly.com article goes to great lengths to discuss the "180-degree change" and "Gaping loophole" but doesn't mention that there are two different types of devices, and that those falling into the "Gaping loophole" category are still covered under Lohr by state liability statutes. It also doesn't mention that even in the previous Lohr decision, a majority of the court did affirm that medical devices that do go through full FDA approval are exempt from state and local requirements, as mentioned in the SCOTUS ruling:

"In Lohr, five Justices concluded that common-law causes of action for negligence and strict liability do impose “requirement[s]” and would be pre-empted by federal requirements specific to a medical device."

I guess even some lawyers don't read Supreme Court decisions, or perhaps only read the media accounts of them, before spouting off.

I do agree that this decision raises the bar a lot, especially with respect to discovery and burden of proof. I expect that truly defective or badly designed devices will still garner lots of class-action suits, as they should. Riegel is a bad case to base too many assumptions on, as it appears it was frivolous to begin with -- the catheter seems to have performed quite well, considering it was inflated 5 times to a pressure 25% over its labeled limit. The real question will be what happens in federal court with a defective device that went through the FDA premarket approval process.

It appears this thread has moved from a technical discussion of the problem to a legal discussion, my point will be on the software safety and technical side. As Mr. Constantine points out there are methods that exist which allow us to identify more precisely potential errors in our software prior to release, testing, or even coding. I would contend that good system engineering and the use of "Formal Methods" and model checking early provides for more predictable behavior. Most software safety problems are not that software developers didn’t follow design & coding guidelines but rather we did not understand the correct behavior in the first place. This is compounded by the fact that the developer is under constant pressure due to cost and time to market constraints placed on them by management. Therefore, we do not take sufficient time to derive a correct solution before we build it (or in the case of software write code). Emphasis should be placed on good system engineering and applying “Formal Methods” and model checking techniques to ensure the problem space is defined and the solution is formally verified prior to coding.