Insiden Therac-25 (2021)

• Mesin radiasi medis Therac-25 mengalami kecelakaan fatal
• Banyak pasien mengalami paparan radiasi berlebih yang parah akibat cacat perangkat lunak
• Masalah muncul setelah sistem keselamatan yang ada diganti dengan sistem kontrol digital
• Kurangnya diagnosis cacat dan komunikasi menyebabkan keterlambatan dalam mengidentifikasi penyebab kecelakaan
• Sebagai pelajaran keselamatan utama, insiden ini menekankan pentingnya keandalan algoritme dan pengujian yang menyeluruh

---

Ringkasan Insiden Therac-25

• Therac-25 digunakan secara luas sebagai perangkat medis radiasi untuk terapi
• Perangkat ini berfungsi memberikan dosis radiasi berkekuatan tinggi kepada pasien kanker
• Perangkat keselamatan interlock mekanis yang digunakan sebelumnya diganti dengan sistem kontrol berbasis perangkat lunak
• Namun, perubahan ini meningkatkan risiko munculnya kesalahan perangkat lunak

Kronologi Terjadinya Kecelakaan

• Cacat pada program muncul pada urutan operasi tertentu atau saat input cepat beruntun
• Akibatnya, perangkat keselamatan tidak berfungsi dengan benar, sehingga pasien menerima radiasi dengan intensitas melebihi rancangan
• Antara 1985 hingga 1987, terjadi beberapa insiden paparan berlebih yang serius pada sejumlah pasien, dan sebagian di antaranya meninggal
• Pada tahap awal, ada kecenderungan untuk mengabaikan masalah perangkat lunak sebagai penyebab cacat pada mesin radiasi

Penyebab Masalah

• Dalam proses verifikasi keandalan, hanya dilakukan pengujian sederhana yang tidak mencerminkan lingkungan klinis nyata
• Penanganan error dan pengelolaan interlock yang kurang memadai menyebabkan kesalahan algoritme dalam situasi ekstrem
• Karena tidak adanya sistem pelaporan masalah dan komunikasi yang jelas antara produsen dan rumah sakit, pengenalan serta penyelesaian cacat menjadi terlambat
• Insiden ini dinilai sebagai kegagalan dalam perancangan perangkat lunak yang berpusat pada keselamatan

Pelajaran Utama

• Dalam merancang algoritme yang berkaitan langsung dengan keselamatan, diperlukan verifikasi menyeluruh dan defensive programming
• Diversifikasi test case dan simulasi berdasarkan skenario penggunaan nyata adalah hal yang wajib
• Pentingnya implementasi yang sistematis untuk berbagai loop penanganan error dan sistem log juga ditekankan
• Di bidang yang menuntut keandalan tinggi, perlu disadari adanya risiko ketergantungan pada kontrol perangkat lunak semata
• Insiden ini merupakan contoh representatif yang mengingatkan industri rekayasa perangkat lunak dan perangkat medis di seluruh dunia akan pentingnya keandalan algoritme, manajemen keselamatan, dan sistem komunikasi

[GN⁺]

Komentar Hacker News

• Ini menegaskan bahwa kualitas perangkat lunak tidak muncul hanya karena ada pengembang yang hebat, melainkan merupakan hasil akhir dari proses di seluruh organisasi. Proses ini memengaruhi bukan hanya praktik pengembangan, tetapi juga pengujian, manajemen, bahkan penjualan dan layanan. Pelajaran yang bisa kita ambil dari kasus Therac-25 adalah bahwa type system, unit test, atau penulisan kode defensif saja tidak menyelesaikan semuanya. Menurut saya, kegagalan yang sebenarnya adalah karena pelaporan insiden, investigasi, dan perbaikannya memakan waktu terlalu lama. Baru-baru ini hal ini juga dibahas di podcast Cautionary Tales, dan yang paling mengesankan adalah bahwa pada Therac-25, pengguna terus mengalami error yang tidak diketahui, tetapi hal itu tidak tersampaikan dengan benar kepada orang yang bisa memperbaikinya. (tautan podcast)

  • Saya tidak setuju dengan pendapat ini. Saya punya pengalaman panjang dalam desain komponen pesawat, dan prinsip intinya hanya satu: satu kegagalan tunggal tidak boleh langsung berujung pada kecelakaan. Cara mewujudkannya bukan dengan ‘menulis perangkat lunak yang berkualitas’ atau ‘pengujian yang cukup’, melainkan dengan menyiapkan ‘sistem independen yang dapat mencegah dampaknya bahkan jika perangkat lunak berperilaku seburuk mungkin’. Dalam kasus Therac-25, yang dibutuhkan adalah alat deteksi radiasi yang otomatis memutus jika ambang keselamatan terlampaui, serta desain fisik yang membuat pelepasan radiasi berlebih menjadi mustahil.

  • Saya juga tadinya ingin merekomendasikan podcast itu. Sangat layak didengarkan, terutama jika tertarik pada bug perangkat lunak. Fakta menariknya, perangkat yang pada awalnya dioperasikan secara manual juga memiliki cacat yang sama, tetapi karena fuse putus akibat korsleting, cacat itu tidak sampai terwujud. Ini bisa dibilang contoh yang sangat baik dari Swiss Cheese Model (referensi Swiss Cheese Model)

  • Saya ingin menekankan bahwa sebagian besar perangkat lunak tidak berhubungan langsung dengan nyawa manusia. Dalam kebanyakan kasus, kegagalan hanya berarti halaman dimuat lebih lambat, laporan penuh dengan NaN, atau batch job harus dijalankan manual. Jarang sekali ada orang yang benar-benar meninggal karena masalah kualitas perangkat lunak, dan saya rasa para pengembang yang membuat perangkat lunak semacam itu sangat sadar akan tanggung jawab mereka.

  • Perusahaan tempat saya bekerja membuat peralatan fotografi dan ilmiah dengan kualitas terbaik. Harganya sangat mahal, tetapi pelanggan mengakui nilainya. Saya benar-benar merasakan bahwa kualitas bukan sekadar hasil dari proses, melainkan pada akhirnya lahir dari ‘budaya’.

  • Banyak pengembang berpikir bahwa jika mereka tidak menangani sistem dengan keandalan tinggi, maka isu kualitas tidak ada hubungannya dengan mereka, dan itu sepenuhnya salah. Kegagalan perangkat lunak yang tampak sepele pun bisa berdampak besar pada hidup seseorang atau pada sebuah perusahaan. Misalnya dengan menghambat alur penting, merusak data hidup atau rekam medis, atau membuat orang tidak bisa membayar barang yang benar-benar mereka butuhkan.

• Menarik ada komentar di artikel yang menyebut bahwa pada era 80-an hingga 90-an, di bidang medis ada persepsi kuat bahwa komputer itu berbahaya. Bahkan sampai awal hingga pertengahan 2000-an, rekam medis masih ditulis tangan di atas kertas. Saya pernah sebentar ikut dalam proyek eksperimen rekam pasien elektronik di ICU, dengan peran mengelola server, dan semua tenaga medis sangat membenci sistem itu. Waktu itu bahkan belum ada tablet, jadi melihat atau mengubah catatan lewat komputer terasa tidak praktis. Semua resep obat biasa langsung ditulis di chart di samping tempat tidur, sehingga bisa segera diperiksa dan dikoreksi. Kehilangan informasi atau keterlambatan akses bisa berakibat fatal, jadi para dokter bukannya membenci komputer tanpa alasan, tetapi memang merasa komputer lebih berbahaya daripada pena dan kertas. Saya rasa situasinya sekarang sudah membaik, tetapi ini tetap sesuatu yang perlu diingat.

  • Sekarang perusahaan seperti Chipsoft nyaris memonopoli dunia IT rumah sakit. Mereka menarik biaya yang sangat mahal, tetapi kualitas perangkat lunaknya buruk sekali, dan makin besar vendornya, makin sedikit pula alternatifnya. Saya tidak mengerti kenapa kita membiarkan vendor yang begitu bermusuhan seperti ini.

  • Masih ada kasus ketika tenaga medis harus kembali ke pena dan kertas karena sistem komputer mati. Saya tidak habis pikir kenapa sistem seperti ini tidak punya redundansi. Mengejutkan bahwa ini justru merupakan produk komersial saat ini.

  • Di Amerika Serikat dan Eropa, EMR (rekam medis elektronik) tidak diklasifikasikan sebagai medical device, sehingga bebas dari banyak regulasi. Tautan artikel terkait

• Menarik jika dibandingkan dengan skandal Kantor Pos Inggris. Kasusnya sama sekali berbeda, tetapi di keduanya ada asumsi keliru yang sama: ‘perangkat lunak tidak mungkin salah’. Dari sudut pandang pengembang ini terdengar sangat lucu, tetapi bagi orang nonteknis, rapuhnya perangkat lunak sulit dipahami. Ada budaya yang berangkat dari asumsi bahwa perangkat lunak pasti tidak cacat, sehingga pengujian pun tidak dilakukan dengan benar.

  • Faktanya, bahkan pengembang pun sering terlalu percaya pada perangkat lunak. Saya selalu menganggap semua sistem yang saya bangun bisa runtuh kapan saja. Karena itu saya tidak akan pernah naik mobil swakemudi. Saya heran pengguna HN tampaknya sangat suka menjadi beta tester untuk teknologi baru. Memang ada klaim bahwa mobil swakemudi secara statistik lebih aman, tetapi salah satu alasannya adalah pengemudi di sekitarnya mengemudi dengan lebih hati-hati. Selain itu, mobil swakemudi adalah sistem baru yang tidak menerapkan pengawasan dan intervensi langsung manusia atau standar yang ketat, dan menurut saya itulah masalahnya.

  • Dalam kebanyakan mesin listrik-mekanis tradisional, keausan komponen adalah kegagalan utama, dan karena perangkat lunak tidak aus, orang jadi keliru percaya bahwa perangkat lunak tentu lebih andal.

  • Saya rasa skandal Kantor Pos jauh lebih jahat. Eksekutif puncak mendapat insentif berdasarkan jumlah uang yang dipungut dari para pemilik kantor pos, dan mereka juga berbohong kepada pengadilan serta para menteri tentang keandalan perangkat lunak itu. Dibandingkan itu, Therac-25 lebih dekat ke kesalahan yang jujur.

• Saya punya firasat bahwa kasus mirip Therac-25 akan segera terjadi lagi. Terlalu banyak orang menjalankan AI agent dalam mode YOLO, jadi jika model seperti Claude atau Gemini tersambung salah ke perangkat keras nyata, rasanya suatu hari akan berujung pada kecelakaan. AI berbasis agent masih kurang matang untuk bidang embedded system, dan membayangkan AI diterapkan secara sembrono pada area seperti peralatan radiasi saja sudah menakutkan.

  • Dalam kasus Horizon di Kantor Pos Inggris, beberapa pemilik cabang bunuh diri dan puluhan kehidupan hancur. Saya rasa kita perlu belajar dari Therac-25 bahwa semua perangkat lunak itu penting. Semua perangkat lunak punya risiko menyakiti seseorang, jadi kita harus selalu berhati-hati.

  • AI non-agent pun sudah, menurut beberapa definisi, 'membunuh orang'. Baru-baru ini ada kasus bunuh diri yang dipicu chatbot AI dan menjadi topik hangat, dan jika ke depan AI dipakai di area keputusan penting seperti asuransi kesehatan, kemungkinan kejadian ‘meninggal karena AI’ akan makin banyak. AI sudah menyebabkan kecelakaan yang merenggut nyawa di berbagai tempat, seperti mobil swakemudi. Bahkan bug sepele seperti kesalahan Excel pun pernah berdampak sosial pada puluhan ribu hingga ratusan ribu orang. Namun AI juga kemungkinan akan punya banyak celah untuk menghindari tanggung jawab seperti pada kasus Horizon karena garis tanggung jawabnya tidak jelas. Saya juga merasa alat AI copilot masih lemah untuk bidang embedded.

  • Krisis 737 MAX MCAS memang merupakan kegagalan tingkat sistem, tetapi ini adalah contoh representatif dari masalah besar kualitas perangkat lunak seperti ini. Saya rasa bencana semacam ini akan terulang lagi di masa depan.

  • Kecelakaan jatuhnya Boeing 737 MAX juga merupakan contoh representatif ketika perangkat lunak berkualitas rendah merenggut sekitar 350 nyawa (tautan info MCAS)

  • Ketika saya mencoba pekerjaan embedded dengan AI agent terbaru, performanya jauh di bawah harapan. Bahkan pada web app CRUD sederhana pun, jika model datanya menjadi kompleks, saya sering melihat LLM bingung hanya setelah dua atau tiga tahap transformasi. Misalnya input-nya created_at, penyimpanannya created_on, dan saat dikirim ke sistem eksternal menjadi last_modified; kalau nama field berbeda seperti ini, masalah pun muncul.

• Kesan yang kuat bagi saya adalah kisah bahwa pada mesin Therac-25, input tombol tertentu melalui terminal VT100 bisa menyebabkan paparan radiasi berlebih dalam sekejap. Pengguna yang berpengalaman bisa menekan tombol dengan cepat dalam waktu 8 detik, dan dalam kasus ini input tidak tercermin dengan benar sehingga berujung pada kecelakaan fatal. Melihat masalah seperti ini, tren masa kini yang juga membawa antarmuka industri dan kendaraan ke layar sentuh terasa mengkhawatirkan.

  • Dalam UI, demi meningkatkan pengalaman pengguna, sering digunakan pendekatan optimistic update, sehingga tampilan berubah cepat tetapi penerapan nyatanya baru disinkronkan kemudian. Saya harap orang benar-benar menyadari di mana pendekatan ini tidak boleh digunakan.

  • Pada kalkulator iOS 11, ada kasus di mana jika “1+2+3” dimasukkan dengan cepat, hasilnya tidak dihitung dengan benar (kasus HN terkait). Bahkan kalkulator yang tampak sepele pun memiliki mode kegagalan yang sama.

• Saya penasaran apakah ada yang pernah mempelajari kasus seperti Therac-25 atau contoh keselamatan/etika seperti ini di kampus. Saya sendiri mempelajari kasus ini di kelas teknik umum bersama kurva bathtub dan metode perhitungan pompa pendingin redundan, dan saya penasaran apakah materi seperti ini masih masuk kurikulum sekarang.

  • Di kelas antarmuka mesin di Purdue pada awal 90-an, konsep ‘hysteresis’ (respons tertunda) ditekankan. Sistem analog tidak berhenti seketika seperti komputer, dan dalam rentang operasinya bisa menunjukkan berbagai perilaku, jadi hal ini wajib diperhitungkan.

  • Topik serupa dibahas di kelas system engineering. (tautan kelas MIT)

  • Saya mempelajari kasus seperti ini dalam program ilmu komputer tingkat universitas atau lebih tinggi. Setelah itu, saat bekerja di medtech, hal itu terus terlintas di pikiran saya.

  • Saya ingat di kelas etika teknik kami benar-benar hanya mempelajari Tacoma Narrows dan Therac-25. Itu pun selesai dalam kuliah satu jam.

  • Karena penasaran, saya membuat survei sendiri. Saya ingin tahu apakah orang lain punya pengalaman mengikuti kelas terkait. (tautan survei)

• Perangkat sebelumnya memiliki hardware interlock. Bahkan jika perangkat lunaknya bermasalah, dampaknya hanya sebatas ketidaknyamanan. Namun karena terlalu percaya bahwa perangkat lunak itu stabil, hardware interlock dihapus demi penghematan biaya dan pengawasan hanya mengandalkan perangkat lunak. Akibatnya, masalah kecil berubah menjadi tragedi fatal. Ini contoh representatif dari disonansi yang terjadi di posisi masing-masing.

• Penulis komentar pertama di artikel itu adalah seorang dokter sekaligus lulusan ilmu komputer, dan juga ketua organisasi profesi terkait pencegahan kekerasan terhadap anak (tautan profil). Namun dalam penilaian medis kekerasan terhadap anak, masih ada banyak celah yang berasal dari data dan bukti yang keliru, serta circular reasoning yang bersifat eksploratif. Sulit menemukan kebenaran yang objektif, dan di lapangan ada kecenderungan untuk menganggap hanya dari beberapa temuan saja sudah cukup untuk menyimpulkan ‘kekerasan terhadap anak tanpa keraguan’. Belakangan, mulai muncul AI black-box yang mengklaim mampu mendeteksi dengan presisi tinggi berdasarkan data yang tidak sempurna seperti ini, tetapi mustahil mendapatkan prediksi yang benar dari data yang salah (garbage in, garbage out). Saya khawatir diagnosis AI yang tidak akurat akan menyebabkan tuduhan palsu kekerasan terhadap anak, kehancuran keluarga, hukuman yang salah, dan akibat serius lainnya. (referensi terkait, paper klinis, masalah AI dan data, tautan riset)

• Laporan tahun 1993 menyebut perlunya kualifikasi bagi software engineer untuk perangkat lunak safety-critical. Tidak seharusnya seseorang bisa mengaku sebagai pengembang perangkat lunak safety-critical hanya setelah beberapa kali pelatihan pemrograman, dan diperkirakan bahwa jika insiden seperti Therac-25 terulang, sertifikasi terkait akan menjadi wajib. Di Inggris bahkan sudah ada pembahasan tentang perancangan kurikulum pelatihan wajib. Namun kini, 32 tahun kemudian, kenyataannya jauh dari harapan itu.

  • Saya telah bekerja selama 15 tahun sebagai profesional software engineer terdaftar di Kanada, tetapi tidak merasakan manfaat praktis yang nyata, jadi saya berencana berhenti memperpanjang sertifikasi itu. Dulu pernah ada diskusi untuk menjadikan pengembangan perangkat lunak sebagai bidang rekayasa yang lebih terstruktur, tetapi sekarang tampaknya sebagian besar sudah menghilang.

  • Perangkat lunak safety-critical tidak dipelajari di ruang kelas, melainkan dibangun lewat pengalaman kerja panjang dan pelatihan. Meski ada standar seperti Do-178 di penerbangan dan IEC 61508 di industri, tingkat penerapan nyatanya tetap bergantung pada anggaran dan jadwal. Namun ketika kecelakaan terjadi, semua hasil audit itu tidak berarti apa-apa dari sudut pandang korban. Semua regulasi dan aturan pada akhirnya lahir setelah seseorang menjadi korban.

• Semua perangkat lunak Therac-25 ditulis oleh satu orang pengembang, dan setelah ia meninggalkan perusahaan pada tahun 1986, identitasnya tidak pernah diungkap. Banyak pembaca mungkin membayangkan bahwa ‘pengembang itu menghasilkan banyak uang dari tragedi ini dan menikmati pensiun mewah’, tetapi pada masa itu, tidak seperti sekarang, pengembang dibayar rendah dan nyaris tidak mendapat pengakuan. Pada era 80-an, pemeran utama di perusahaan teknologi adalah tenaga penjualan, dan sangat mungkin komisi penjualan Therac-25 melebihi gaji tahunan sang pengembang. Terutama jika melihat lokasi AECL, konteks zamannya, sifatnya yang semi-pemerintah, dan karakter embedded software, semuanya menunjuk ke upah rendah. Pada 1986 nilainya sekitar CAD $30.000–$50.000, dan bahkan jika dikonversi ke nilai sekarang hanya sekitar US$78.000–$129.000, tanpa stock option.