The Panama radiation overdose incident and software design failures

Software can kill. A lesson how the database has to be managed in congruence with the workplace in order to save, rather than destroy, lives.

Summary of the case

Due to unclear and uncoordinated assembly and construction of the software system, 28 patients at the National Center Institute of Panama received excessive does of gamma ray radiation of cancer treatment in November 2000. 21 of those patients, according to the International Atomic Energy Agency (IAEA) died due to radiation poisoning and three Panamanian medical physicists who used the software to figure out the needed dose of radiation of the patients were charged with second-degree murder.

The fault of these physicians were that they introduced changes in the software for radiation procedures on the patients without thoroughly ascertaining that the software was accurately following modification instructions according to intended and prescribed details.

Chemotherapy is a calculated and precise business. Treatment of the patient determines careful localization of the tumor area and putting blocks around the area that will not be treated. Medical physicists, thereupon, feed into relevant software the size, shape, and location of the blocks in order to direct the radiation solely and only to the tuberous area. The physicists in question, in this case, were following the doctor's instructions to add a fifth block to the four blocks ordinarily used on cancer patients, but they were not aware of the fact that the radiation machine software, created by Multi-data System International of Missouri, was designed for only four or fewer blocks. One of the physicians, thereupon, tried to make the software work by entering the dimensions of all five blocks into a single shape. The software miscalculated appropriate doses and patients received 20 to 25% more radiation than they should have.

Multidata insisted that it did nothing wrong since it was the responsibility of the user to verify the results of the software's calculations before application

Unfortunately, the hospital physicians often work under stress and, therefore, tend to rely on the software system and fail to manually verify the results of the calculations.

Concern had been voiced in the past, and independent experts had recommended that the software should be designed to pause or shut down if told to execute a task that was beyond its designation.

In 2001, the IAEA found that the software miscalculated treatment times of blocks that were coordinated into a single shape and that the manual failed to provide clear instruction on how to digitize coordinates of shielding blocks. Moreover, the manual failed to provide warnings against implementing approaches that would differ from its standard procedures.

The U.S. Food and Drug Administration (FDA) discovered, in 2001, that Multdata had received numerous complaints on calculation errors related to their inability to handle certain types of blocks correctly but that they had, time and again, ignored these complaints. In 2003, Multidata agreed not to make or sell software for radiation therapy devices in America, although it still sells its products abroad.

Proposing a solution

Before an organization implements a software system, it needs to first extensively research that software system to make sure that it is slanted for its needs.

The initial scenario may have been worked out in one of two ways: (1) the Hospital may have worked in unions with the system engineers of the software system to devise ways of linking their software strategies and processes to the organization's objectives. Objectives of the medical institution should be thoroughly scrutinized, and understanding should exist between engineer and business managers regarding the way the software will meet expectations and needs (Yusuf, Gunasekaran, & Abthorpe, 2004).

The compute software could also have been configured to allow the customer to rewire part of the delivered functionality, writing a homegrown bolt-on / add-on module within the system, or interfacing to an external system. Most importantly, Multidata should have provided a manual that clearly addresses its purposes, capacities, and limitations, with clear warning as to danger were its limitations to be ignored.

Learning application

The importance of conducting thorough background research on any piece of software before purchasing it, as well as running consumer research on consumer satisfaction with the product and testing it out various times before applying. The more important its purpose, the greater the necessity that these requirements be fulfilled.