Skip to content Skip to navigation Skip to collection information

Connexions

You are here: Home » Content » The Environments of the Organization » Case Analysis Module: Therac-25

Navigation

Lenses

What is a lens?

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

This content is ...

Affiliated with (What does "Affiliated with" mean?)

This content is either by members of the organizations listed or about topics related to the organizations listed. Click each link to see a list of all content affiliated with the organization.
  • OrangeGrove display tagshide tags

    This module is included inLens: Florida Orange Grove Textbooks
    By: Florida Orange GroveAs a part of collection: "Business Ethics"

    Click the "OrangeGrove" link to see all content affiliated with them.

    Click the tag icon tag icon to display tags associated with this content.

  • EAC Toolkit

    This module is included inLens: Collaborative Development of Ethics Across the Curriculum Resources and Sharing of Best Practices
    By: University of Puerto Rico at Mayaguez - College of Business AdministrationAs a part of collection: "Business Ethics"

    Click the "EAC Toolkit" link to see all content affiliated with them.

Recently Viewed

This feature requires Javascript to be enabled.

Tags

(What is a tag?)

These tags come from the endorsement, affiliation, and other lenses that include this content.
 

Case Analysis Module: Therac-25

Module by: William Frey. E-mail the author

Summary: This module, designed for the EAC Toolkit (NSF SES 0551779) will test the Toolkit and Connexion's ability to network different online and offline sources for ethics across the curriculum. It consists of four components designed to provide students with tools for carrying out an in-depth analysis of the cases found at www.computingcases.org; it also makes substantial references to the draft manuscript of a textbook in computer ethics entitled Good Computing: A Virtue Approach to Computer Ethics. (The book will consist of the cases displayed at Computing Cases--Therac-25, Hughes Aircraft, and Machado--plus seven additional cases all developed through NSF projects DUE-9972280 and DUE 9980768.) The module presents the case abstract and timeline. It then refers students to Computing Cases where they will find the case narrative, history, and supporting documents that provide background necessary for analysis. The case abstract and timeline introduce students to the basic outlines of the case. The accompanying decision point taken from the case provides students with the necessary focus to carry out an in-depth analysis. Students respond to the decision point by working through four stages: problem specification, solution generation, solution testing, and solution implementation.

Computer Ethics

Case Module Template

By William J. Frey

Module Introduction:

The Therac-25 case is what Huff and Frey call a thick, historical, evaluative, big news and bad news case. Tackling cases of this complexity requires both careful thought and considerable skill. Especially important is the ability to sift through the case details, documents, and conflicting narratives. The purpose of this module is to provide students with a structure to tackle big, long, and complicated cases. Students will receive frameworks to help them structure the case's ethical and social problems. They will also be provided with decision points that will help them to enter into the case and take up the standpoint of a participant. The module presented below can be linked to materials that can be found at www.computingcases.org. Nancy Leveson, in Safeware:System Safety and Computer (515-553), also provides an excellent and comprehensive account. Excellent advice on how to teach the case, updated information, and clear explanations of the programming errors are provided by Chuck Huff and Richard Brown in "Integrating Ethics into a Computing Curriculum: A Case Study of the Therac-25." The materials posted at Computing Cases were all developed through NSF projects DUE-9972280 and DUE 9980768.)

The module presents the case abstract and timeline. It then refers students to computingcases.org where they will find the case narrative, history, and supporting documents that provide background information necessary for analysis. The case abstract and timeline introduce students to the basic outlines of the case. The accompanying decision point taken from the case provides students with the necessary focus to carry out an in-depth analysis. Students respond to the decision-point by working through the four stages: problem specification, solution generation, solution testing, and solution implementation.

Module Activities:

1. Instructor introduces the case based on the abstract and timeline found at www.computingcases.org

2. Students read case abstract, timeline, case decision point, and case analysis exercises.

3. Students do further research into the case by consulting ComputingCases materials which include narratives, histories, supporting documents, and ethical analyses.

4. Students carry out the activities outlined in the accompanying case exercises by (a) specifying the problem raised in the decision point, (b) generating solutions, (c) testing solutions using ethics tests, and (d) developing plans for implementing the solution over situational constraints.

5. Students prepare their case analyses working in small groups.

6. These groups present their completed analysis to the class in a case-debriefing session.

7. The instructor concludes by discussing the problem-solving issues and intermediate moral concepts raised by the case.

Therac-25 Abstract

Therac-25was a new generation medical linear acceleratorfor treating cancer. It incorporated the most recent computer control equipment. Therac-25’s computerization made the laborious process of machine setup much easier for operators, and thus allowed them to spend minimal time in setting up the equipment. In addition to making setup easier, the computer also monitored the machine for safety. With the advent of computer control, hardware based safety mechanisms were transferred to the software. Hospitals were told that the Therac-25 medical linear accelerator had "so many safety mechanisms" that it was "virtually impossible" to overdose a patient. Normally, when a patient is scheduled to have radiation therapy for cancer, he or she is scheduled for several sessions over a few weeks and told to expect some minor skin discomfort from the treatment. The discomfort is described as being like a mild sunburn over the treated area. But in this case on safety critical software, you will find that some patients received much more radiation than prescribed

Therac - 25 Timeline

This time line is largely adopted from the Computing Cases website. The website developer, Charles Huff, has provided this module's author with a more detailed unpublished version (that provides the real names of the patients left out in Computing Cases) that the author has adopted here. Readers should note that this time line also overlaps with that provided by Leveson and Turner. (See below for two references where the Turner and Leveson time line can be found.)

Table 1: Therac-25 Chronology
Chronology closely paraphrases chronology in Computing Cases. The major difference is that it replaces fictional names with real names of participants since these were eventually publicized. Most of these events were originally uncovered by Leveson. (See citations below)
Early1970’s AECL and a French Company (CGR) collaborate to build Medical Linear Accelerators (linacs). They develop Therac-6, and Therac-20. (AECL and CGR end their working relationship in 1981.)
1976 AECL developes the revolutionary "double pass" accelerator which leads to the development of Therac-25.
March, 1983 AECL performs a safety analysis of Therac-25 which apparently excludes an analysis of software.
July 29,1983 In a PR Newswire the Canadian Consulate General announces the introduction of the new "Therac 25" Machine manufactured by AECL Medical, a division of Atomic Energy of Canada Limited.
ca. Dec. 1984 Marietta Georgia, Kennestone Regional Oncology Center implements the new Therac-25 machine.
June 3, 1985 Marietta Georgia, Kennestone Regional Oncology CenterKatherine (Katy) Yarbrough, a 61-year-old woman is overdosed during a follow-up radiation treatment after removal of a malignant breast tumor. Tim Still, Kennestone Physicist calls AECL asking if overdose is possible; three days later he is informed it is not.
July 26, 1985 Hamilton, Ontario, Canada. Frances Hill, a 40-year-old patient is overdosed during treatment for cervical carcinoma. AECL is informed of the injury and sends a service engineer to investigate.
   
November 3, 1985 Hamilton Ontario patient dies of cancer, but it is noted on her autopsy that had she not died, a full hip replacement would have been necessary as a result of the radiation overdose.
November 8, 1985 Letter from CRPB to AECL requesting additional hardware interlocks and changes in software. Letter also requested treatment terminated in the event of a malfunction with no option to proceed with single key-stroke. (under Canada’s Radiation Emitting Devices Act.)
   
November 18, 1985 Katy Yarbrough files suit against AECL and Kennestone Regional Oncology Center. AECL informed officially of Lawsuit.
December 1985 Yakima Valley Memorial Hospital, Yakima Washington. A woman being treated with Therac-25 develops erythema on her hip after one of the treatments.
January 31, 1986 Staff at Yakima sends letter to AECL and speak on the phone with AECL technical support supervisor.
February 24, 1986 AECL technical support supervisor sends a written response to Yakima claiming that Therac-25 could not have been responsible for the injuries to the female patient.
March 21, 1986 East Texas Cancer Center, Tyler Texas. Voyne Ray Cox is overdosed during treatment on his back. Fritz Hager notifies AECL. Company suggests some tests and suggests hospital might have an electrical problem. AECL claims again that overdoes is impossible and that no other accidents have occurred previously.
March 22, 1986 Ray Cox checks into an emergency room with severe radiation sickness. Fritz Hager calls AECL again and arranges for Randy Rhodes and Dave Nott to test Therac. They travel to Texas and test Therac but find nothing wrong.
April 7, 1986 ETCC has investigated electrical problem possibility, finding none, put Therac-25 back in service.
April 11, 1986 East Texas Cancer Center. Another Verdon Kidd is overdosed during treatments to his face. Operator is able to explain how Malfuction 54 was achieved. Fritz Hager tests computer’s readout of no dose, and discovers the extent of the overdoses. Hager spends weekend on phone with AECL explaining findings.
April 14, 1986 AECL files report with FDA. AECL sends letter to Therac-25 users with suggestions for avoiding future accidents, including the removal of the up-arrow editing key and the covering of the contact with electrical tape.
May 1, 1986 Verdon Kidd, who was to have received treatments to left ear dies as a result of acute radiation injury to the right temporal lobe of the brain and brain stem. He is the first person to die from therapeutic radiation accident.
May 2, 1986 FDA declares Therac-25 defective, and their "fix" letter to users inadequate. FDA demands a CAP from AECL.
June 13, 1986 AECL produces first CAP for FDA.
July 23, 1986 FDA has received CAP, asks for more information.
August, 1986 Therac-25 users create a user group and meet at the annual conference of the American Association of Physicists in Medicine
August, 1986 Ray Cox, overdosed during back treatment, dies as a result of radiation burns.
September 23, 1996 Debbie Cox and Cox family file lawsuit
September 26, 1986 AECL provides FDA with more information.
October 30, 1986 FDA requests more information.
November 1986 Physicists and engineers from FDA’s CDRH conducted a technical assessment of the Therac-25 at AECL manufacturing plant in Canada (R.C. Thompson).
November 12, 1986 AECL submits revision of CAP.
December Therac-20 users notified of a software bug.
December 11, 1986 FDA requests more changes to CAP.
December 22, 1986 AECL submits second revision of CAP.
January 17, 1987 Second patient, Glen A. Dodd, a 65-year-old man, is overdosed at Yakima.
January 19, 1987 AECL issues hazard notification to all Therac-25 users and told them to visually confirm the position of the turntable before turning on beam.
January 26, 1987 Conference call between AECL quality assurance manager and Ed Miller of FDA. AECL sends FDA revised test plan. AECL calls Therac users with instructions on how to avoid beam on when turntable is in field light position.
February 3, 1987 AECL announces additional changes to Therac-25
February 6, 1987 Ed Miller calls Pavel Dvorak of Canada’s Health and Welfare department with news that FDA will recommend that all Therac 25 units be taken out of service until CAP is completed.
February 10, 1987 FDA sends notice to AECL advising that Therac is defective under US law and requesting AECL to notify customers that it should not be used for routine therapy. Canadian Health Protection Branch does the same.
March 1987 Second User Group Meeting
March 5, 1987 AECL sends third revision of CAP to FDA.
April 1987 Glen A. Dodd, overdosed at Yakima, dies of complications from radiation burns to his chest.
April 9, 1987 FDA asks for additional information regarding third CAP revision.
April 13, 1987 AECL sends update of CAP and list of nine items requested by users at March meeting.
May 1, 1987 AECL sends fourth revision of CAP to FDA as a result of FDA commentary at user meeting.
May 26, 1987 FDA approves fourth CAP subject to final testing and analysis.
June 5, 1987 AECL sends final test plans to FDA along with safety analysis.
July, 1987 Third Therac-25 User Group Meeting
July 21, 1987 AECL sends final (fifth) CAP revision to FDA.
January 28, 1988 Interim safety analysis report issued from AECL.
November 3, 1988 Final safety analysis report issued.
 

Scenario: You are an engineer working for AECL sent to investigate an alleged overdosing incident at the Ontario Cancer Foundation in Hamilton. Ontario. The following is the description provided to you of what happened:

On July 26, 1985, a forty-year old patient came to the clinic for her twenty-fourth Therac-25 treatment for carcinoma of the cervix. The operator activated the machine, but the Therac shut down after five seconds with an HTILT error message. The Therac-25’s console display read NO DOSE and indicated a TREATMENT PAUSE

Since the machine did not suspend and the control display indicated no dose was delivered to the patient, the operator went ahead with a second attempt at a treatment by pressing the Proceed Command Key, expecting the machine to deliver the proper dose this time. This was standard operating procedure, and Therac-25 operators had become accustomed to frequent malfunctions that had no untoward [bad] consequences for the patient. Again the machine shut down in the same manner. The operator repeated this process four times after the original attempt—the display showing NO DOSE delivered to the patient each time. After the fifth pause, the machine went into treatment suspend, and a hospital service technician was called. The technician found nothing wrong with the machine. According to a Therac-25 operator, this scenario also was not unusual.

After treatment, the patient complained of a burning sensation, described as an “electric tingling shock” to the treatment area in her hip….She came back for further treatment on July 29 and complained of burning, hip pain, and excessive swelling in the region of treatment. The patient was hospitalized for the condition on July 30, and the machine was taken out of service. (Description taken from Nancy Leveson, Safeware, pp 523-4)

You give the unit a thorough examination and are able to find nothing wrong. Working with the operator, you try to duplicate the treatment procedure of July 26. Nothing out of the ordinary happens. Your responsibility is to make a recommendation to AECL and to the Ontario Cancer Foundation. What will it be?

1. Identify key components of the STS

Table 2
Part/Level of Analysis Hardware Software Physical Surroundings People, Groups, & Roles Procedures Laws & Regulations Data & Data Structures
 
             
             
             

2. Specify the problem:

2a. Is the problem a disagreement on facts? What are the facts? What are cost and time constraints on uncovering and communicating these facts?

2b. Is the problem a disagreement on a critical concept? What is the concept? Can agreement be reached by consulting legal or regulatory information on the concept? (For example, if the concept in question is safety, can disputants consult engineering codes, legal precedents, or ethical literature that helps provide consensus? Can disputants agree on positive and negative paradigm cases so the concept disagreement can be resolved through line-drawing methods?

2c. Use the table to identify and locate value conflicts within the STS. Can the problem be specified as a mismatch between a technology and the existing STS, a mismatch within the STS exacerbated by the introduction of the technology, or by overlooked results?

Table 3
STS/Value Safety (freedom from harm) Justice (Equity & Access) Privacy Property Free Speech
Hardware/software          
Physical Surroundings          
People, Groups, & Roles          
Procedures          
Laws          
Data & Data Structures          

3. Develop a general solution strategy and then brainstorm specific solutions:

Table 4
Problem / Solution Strategy Disagreement Value Conflict Situational Constraints
  Factual Conceptual Integrate? Tradeoff? Resource?Technical?Interest

3a. Is problem one of integrating values, resolving disagreements, or responding to situational constraints?

3b. If the conflict comes from a value mismatch, then can it be solved by modifying one or more of the components of the STS? Which one?

4. Test solutions:

Table 5
Alternative / Test Reversibility Value: Justice Value: Responsibility Value: Respect Harm Code
A #1            
A #2            
A #3            

5. Implement solution over feasibility constraints

Table 6
Alternative Constraint Resource Interest Technical
  Time Cost Individual Organization Legal/ Social Available Techno-logy Manufacturability
#1              
#2              
#3              

Appendix

Therac Decision Point Presentation

Media File: Therac-25 Case_V3.pptx

Media File: Therac-25 Case_V4.pptx

Therac-25 Decision Point

Media File: Therac-25_DP.pptx

Therac-25 Case Summary

Media File: Therac-25 Case_V6.pptx

Free and Informed Consent, Safety, and Dimensions of Risk

Media File: Therac-25 Case_V7.pptx

References

  • Nancy G. Leveson. Safeware: System Safety and Computers. New York: Addison-Wesley Publishing Company, 515-553.
  • Nancy G. Leveson and Clark S. Turner. An Investigation of the Therac-25 Accidents. Computers, Ethics, and Social Values, Johnson, D.G. and Nissenbaum, H., eds.: 478.
  • Nancy G. Leveson and Clark S. Turner. An Investigation of the Therac-25 Accidents. IEEE Computer. 26(7): 18-41, July 1993.
  • Computing Cases website. See above link. Materials on case including interviews and supporting documents.
  • Sara Baase. A Gift of Fire: Social, Legal, and Ethical Issues in Computing. Upper Saddle River, NJ: Prentice-Hall, 125-129.
  • Chuck Huff. Good Computing: A Virtue Approach to Computer Ethics. Draft for course CS-263. June 2005.
  • Chuck Huff and Richard Brown. Integrating Ethics into a Computing Curriculum: A Case Study of the Therac-25. Available at Computing Cases website. See above link.
  • For time line see: http://computingcases.org/case_materials/therac/supporting_docs/therac_resources/Timeline.html
  • Leveson in Safeware provides an excellence summary of the literature on system safety. For two further excellent resources consult the next two references.
  • Perrow, C. (1984) Normal Accidents: Living with high-risk technologies. Basic Books, NY,NY.
  • Reason, J. (1990/1999) Human Error Cambridge University Press: London.

Collection Navigation

Content actions

Download:

Collection as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Module as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Add:

Collection to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks

Module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks