Electrical Engineering Case Study: Therac-25 Incident Analysis

This case study analyzes the Therac-25 incident, a medical device that caused patient deaths due to software errors and inadequate safety measures. The assignment discusses the responsibilities of Atomic Energy Canada Limited (AECL), the software creators, and the Food and Drug Administration (FDA). The analysis highlights issues such as ineffective software testing, poor record-keeping, and the lack of sufficient safety features. The study emphasizes the need for proper design, rigorous testing, and comprehensive safety protocols in medical devices to minimize risks and ensure patient safety. It also explores the role of the FDA in approving and reviewing medical devices, including the importance of considering different patient needs and comparing updated devices with previous versions to identify and rectify errors. The case underscores the critical importance of ethical considerations in software development and the severe consequences of neglecting safety standards in medical technology.

Electronics
Case study

1. The Company which has developed this device (Atomic Energy Canada Limited (AECL) and CGR in this
case) should be held responsible for the errors in the medical device as the software was ineffectively
tested and “patches” of the software were used from the earlier version of the machine. Also, it was
determined that there was derisory record keeping when the software of the device was
designed/tested. The device had two noticeable software errors, a failed micro-switch, and a reduced
number of safety measures, which lead to the faults in the medical equipment.
2. Creators of the software have overall responsibility for the device as a whole is completely
dependent on the software. Their lack of testing and careless programming could lead to the flaws in the
software and, in turn, lead to mishappening; similar to the case which had happened with Therac -25
machines, which involved six accidents due to overdoses of radiation to patients leading to death
(Gotterbarn, 2002).
3. The first and foremost step of the creators of the software is to focus on the overall design, i.e.,
proper programming, superior testing of the individual component of the system, and sufficient safety
features. These steps are morally required by a software creator so as to minimize the risk of failure of a
device leading to an accident. It is wise to have confidence in your product by adequately working on
the design of the software rather than pointing out foolishly that computers always have problems with
their programming after the failure of the device (Unwrapped, 2020).
4. FDA should have a proper check of the device and approve its roll out only after proper testing of the
product. The medical devices are designed for providing better medical treatment to the patients. Still,
its benefits should not outweigh its harms, i.e., it should not have any adverse effect on any human
being exposed to its usage Leveson, 1995). The device should be 100% safe before approval as it is a
medical device and has to be used on the patients, so the FDA has a decidedly more significant role to
play in this scenario. Yes, FDA guidelines should also keep in consideration the different therapies for
children or patients with rare conditions prior approval of any medical device.

5. The FDA should review updated medical devices as an improvement in the older design because it will
be easy to compare it with the previous version, and its flaws/ errors can easily be identified and
rectified (Nissenbaum, 1994). If reviewed as an improvement, the device could be subjected to a full
review process if the previous version had flaws or errors. If considered as a novel device, it will hamper
the production of the modified/improved methods as it will be more time consuming and incur higher
costs.

References:-
Gotterbarn, D. (2002). Software Engineering Ethics. Retrieved from
https://onlinelibrary.wiley.com/doi/abs/10.1002/0471028959.sof314
Leveson, N. (1995). Medical Devices-The Threac-25. Retrieved from
http://sunnyday.mit.edu/papers/therac.pdf.
Nissenbaum, H. (1994). Computing and accountability. Communications Of The ACM, 37(1), 72-80. doi:
10.1145/175222.175228
Therac-25 - Ethics Unwrapped. (2020). Retrieved 6 April 2020, from
https://ethicsunwrapped.utexas.edu/case-study/therac-25