Monthly Archives: August 2010

Never Event

Feeding Tube Misconnection Results in Patient, Fetus Death

By ThinkReliability Staff

Recent articles have related several stories of patients being injured or even killed by medical tubing mix-ups.  A product used other than intended that results in a patient death is one of the “Never Events” – events that should never happen at healthcare facilities.   An article in The New York Times discusses injuries and deaths caused by accidentally connecting food meant for a feeding tube through an intravenous (IV) line.    A specific incident mentioned in the article can be analyzed in a Cause Map to capture all of the causes in a simple, intuitive format that fits on one page.

In this case, a pregnant woman was prescribed a feeding tube to ensure that she and her baby were getting adequate nourishment.  The feeding tube was improperly connected to the intravenous (IV) line, causing liquid food to enter her veins, causing sepsis which killed her and her fetus.

One issue (cause) is that medical personnel made an incorrect connection.  Although there was no information given in the article, this would certainly be an area for the responsible organization to look at in more detail and determine if there are steps that can be taken to reduce the risk of these types of errors.  (Some organizations have found success with color coding the tubes, for example.)

However, another issue is that the tubes COULD be incorrectly connected in the first place.  The number of errors in feeding tube connections (discussed in an article from The Joint Commission Journal on Quality and Patient Safety) has led the U.S. Food and Drug Administration (FDA) to consider declaring these products unsafe.

The tubes become compatible with other tubing connections (such as IV) when needle-free connectors were adopted, to increase caregiver safety (by limiting exposure to needles).  Since then, there have been issues with the compatible tubing.  (A history of tubing issues is found on the PDF, which can be downloaded by clicking “Download PDF” above.)   And, feeding tube connections that are incompatible with other tubing lines are difficult to find.  There are many causes given for the delay of developing incompatible tubing, including resistance from the medical industry, difficulties with the FDA approval process, and a delay in forwarding requirements for incompatible tubing.  This delay is mainly attributed to waiting for an international group to develop a recommendation regarding tubing, which is expected to take several years.

The FDA has an expedited review process which allows approval of a device if it works like an already approved device, regardless of whether that device is safe, or has been recalled.  Because compatible tubing devices have already been approved, new devices that use the same – compatible – connection can go through this expedited process, whereas incompatible connections can not.  Without federal agencies requiring change, it’s been difficult getting manufacturers to update their products.

View the problem outline, Cause Map, and timeline of tubing issues by clicking “Download PDF” above.

Never Event

Cardiac Arrest Due to Leaky Equipment

By ThinkReliability Staff

A patient death associated with equipment that does not perform properly is one of the “Never Events” (i.e. events that should never happen).  A case where a leaking piece of equipment caused the cardiac arrest of a child is described by the ECRI Institute.  We can record this information in a Cause Map, or visual root cause analysis in order to show the relationships between the causes and suggested solutions.  The root cause analysis investigation can be seen by clicking on “Download PDF”.

Because a patient suffered cardiac arrest, there was an impact to the patient safety goal.  We begin this impacted goal and ask “Why” questions to add more causes to the Cause Map.  The cardiac arrest was caused by suffocation.  The suffocation was a result of undetected excessive carbon dioxide (CO2) levels.  The levels were undetected because the child was under anesthesia (thus making it difficult to judge the breathing air quality) and because there was no device to detect high CO2 levels.  The CO2 levels were high due to rebreathing.  (The high CO2 levels were an impact to the patient services  and environmental goals as well.)

The rebreathing occurred because of a lower than normal fresh gas (breathing oxygen) flow.  With a breathing system of this type, the rebreathing (or taking in exhaled CO2) is inversely proportional to the fresh gas flow.  As the gas flow decreases, the rebreathing increases.  The reduced fresh gas flow was caused by a leaky humidifier.  (The leaky humidifier can be considered an impact to the property goal.)  The leaky humidifier was caused by an unrepaired pressure drop through the gas flow passages.  The pressure drop was caused by an inadequate seal on those passages due to two (of four) loose screws that were apparently not noticed.

The leak had been detected during the pre-use test of the equipment.  The leak was believed to be repaired, but instead of performing another pre-use test of the equipment, the system was put together, and a test was done on the whole system.  The system has a higher allowed leak rate than each individual piece of equipment, so the fact that the leak was not in fact repaired was not noticed.

Some of the suggestions given by ECRI Institute to prevent this kind of incident from recurring are to install a CO2 detector on the breathing circuit, ensure the anesthesia equipment is on a regular inspection and maintenance program, and to redo individual equipment tests after repairs.

Never Event, Root Cause Analysis

Patient Death from Restraint

By ThinkReliability Staff

A patient death associated with the use of restraints is a “never event” as defined by the National Quality Forum (NQF).  A recent death at a St. Louis, Missouri hospital has placed the hospital at risk of being terminated from the Medicare program after two other recent patient deaths associated with restraints and inappropriate patient seclusion.

In order to shed some light on the issues surrounding this most recent death, we can begin sifting through the facts in a root cause analysis.  First, we enter the necessary information into the outline, including the impact to the goals (to view the outline, timeline and Cause Map, please click on download PDF above).  The impacts to the organization’s goals begin the Cause Map, or visual root cause analysis.  We can continue to add more detail to the Cause Map by asking “Why” questions.

We will then discover that the patient died of suffocation.  An early concern was that the patient’s airway was blocked by gum, but the doctor determined that was not the case.  (We can leave this cause on the Cause Map but can cross it out once it has been determined that it did not contribute to the incident.)  The patient suffocated when she was left facedown on a beanbag chair, after being given a sedative that slowed her breathing, and was not properly monitored for breathing or a pulse.    The patient had been restrained and sedated after threatening and assaulting the hospital staff.  The patient was not constantly supervised, as suggested, possibly due to a lack of staff.

When the charge nurse arrived several minutes later and determined the patient was not breathing, resuscitation was not immediately begun (either mouth-to-mouth or CPR). She first left to get a light, then a stethoscope, then to find the patient’s nurse.  After the patient’s nurse returned, she left to call a “Code Blue”.  The first aide that arrived was told not to begin CPR or mouth-to-mouth because there was no breathing mask.  She did anyway.  Nine minutes later, the doctor inserted a breathing tube.  The staff attempted to restart the patient’s heart but were unsuccessful and she was pronounced dead.

To determine what actions can be taken so that this never happens again, first we have to do a little more research into a few specific areas.  First there needs to be a thorough investigation on the restraint procedure at this hospital.  Because a patient died in restraints, some aspect(s) of the restraint procedure must be improved.  To improve the procedure, however, first we have to know what the hospital staff  actually did, step by step, in this case (and others).  Then we should look at expectations and/or requirements for supervision of patients who are being restrained, or given sedatives, or who, based on their behavior, require constant supervision.  For example, patients who are held facedown need extra supervision to make sure their breathing is not constricted.  Additionally, it may be appropriate to turn the patient back face up once the sedatives begin to work.

The patient’s death was caused in part by the delay in resuscitation.  Beyond the delay in recognizing the patient’s respiratory distress, the expectations for staff in this situation need to be addressed.  Because the charge nurse was fired, it seems that the hospital did not think she properly performed her expected duties, but why?  Perhaps the staff does not understand what they should do in this case, or doesn’t have the necessary equipment (such as a breathing mask) readily available.  Although refresher training might be in order, we don’t stop there.  We need to figure out all the things that are keeping our staff from being able to do what they need to for their jobs and remove those obstacles – BEFORE this happens again.

To view the outline, timeline and Cause Map, click on “Download PDF” above.  To learn more about this incident, please see the news story.

Root Cause Analysis

Therac-25 Radiation Overdoses

By ThinkReliability Staff

The Therac-25 is a radiation therapy machine used during the mid-80s. It delivered two types of radiation beams, a low-power electron beam and a high-power x-ray. This provided the economic advantage of delivering two kinds of therapeutic radiation with one machine. From June 1985 to January 1987, the Therac-25 delivered massive radiation overdoses to 6 people around the country. We can look at the causes of these overdoses in a root cause analysis performed as a Cause Map.

The radiation overdoses were caused by delivery of the high-powered electron beam without attenuation. In order for this to happen, the high-powered beam was delivered, and the attenuation was not present. The lower-powered beam did not require attenuation provided by the beam spreader, so it was possible to operate the machine without it. The machine did register an error when the high-powered beam was turned on without attenuation. However, it was possible to operate the the beam with the error and the warning was overridden by the operators.

The Therac-25 had two different responses to errors. One was to pause the treatment, which allowed the operators to resume without any changes to settings, and another was to reset the machine settings. The error resulting in this case, having the high-power beam without attenuation, resulted only in a treatment pause, allowing the operator to resume treatment with an override, without changing any of the settings. Researchers talking to the operators found that the Therac-25 frequently resulted in errors and so operators were accustomed to overriding them. In this case, the error that resulted (“Malfunction 54”) was ambiguous and not defined in any of the operating manuals. (This code was apparently only to be used for the manufacturing company, not healthcare users.)

The Therac-25 allowed the beam to be turned on without error (minus the overridden warning) in this circumstance. The Therac-25 had no hardware protective circuits and depended solely on software for protection. The safety analysis of the Therac-25 considered only hardware failures, not software errors, and thus did not discover the need for any sort of hardware protection. The reasoning given for not including software errors was the “extensive testing” of the Therac-25, the fact that software, unlike hardware, does not degrade, and the general assumption that software is error-proof. Software errors were assumed to be caused by hardware errors, and residual software errors were not included in the analysis.

Unfortunately the coding used in the Therac-25 was in part borrowed from a previous machine and contained a residual error. This error was not noticed in previous versions because hardware protective circuits prevented a similar error from occurring. The residual error was a software error known as a “race condition”. In short, the output of the coding was dependent on the order the variables were entered. If an operator were to enter the variables for the treatment very quickly and not in the normal order (such as going back to correct a mistake), the machine would accept the settings before the change from the default setting had registered. In some of these cases, it resulted in the error described here. This error was not caught before the overdoses happened because software failures were not considered in the safety analysis (as described above), the code was reused from a previous system that had hardware interlocks (and so had not had these problems) and the review of the software was inadequate. The coding was not independently reviewed, the design of the software did not include failure modes and the software was not tested with the hardware until installation.

This incident can teach us a lot about over-reliance on one part of a system and re-using designs in a new way with inadequate testing and verification (as well as many other issues). If we can learn from the mistakes of others, we are less likely to make those mistakes ourselves. For more detail on this (extremely complicated) issue, please see Nancy Leverson and Clark Turner’s “An Investigation of the Therac-25 Incidents.”