Ketika Tembok Jebol — Merancang Sistem Medis dengan Safety-II

95% yang Kita Abaikan

Pada tahun 2014, Erik Hollnagel menerbitkan sebuah buku yang secara diam-diam mengubah cara para ilmuwan keselamatan berpikir^[1]. Argumennya sederhana namun menggugah: bidang keselamatan telah menghabiskan puluhan tahun mempelajari persentase kecil kasus di mana hal-hal berjalan salah, sementara hampir sepenuhnya mengabaikan mayoritas besar kasus di mana hal-hal berjalan benar.

Ia menyebut pendekatan tradisional sebagai Safety-I — identifikasi mode kegagalan, bangun pertahanan, cegah hasil buruk. Ini adalah fondasi dari setiap daftar periksa (checklist), setiap mekanisme pengaman, setiap dialog konfirmasi. Dan ini berhasil. Kecuali ketika tidak.

Alternatifnya, Safety-II, dimulai dari pertanyaan yang berbeda: alih-alih bertanya mengapa hal-hal kadang gagal, tanyakan mengapa hal-hal biasanya berhasil. Jawabannya bukan "karena kita membangun pertahanan yang baik". Jawabannya adalah "karena manusia beradaptasi". Perawat berimprovisasi. Dokter menyimpang dari protokol ketika protokol tidak sesuai. Staf logistik menemukan solusi alternatif yang tidak direncanakan siapa pun.

Safety-I memperlakukan variasi ini sebagai masalah. Safety-II memperlakukannya sebagai sumber utama ketangguhan (resilience).

Skenario yang Menghancurkan Pemikiran Safety-I Kami

Kami sedang membangun xGrid, platform logistik medis bencana yang berjalan secara luring (offline) pada perangkat Raspberry Pi. Di awal pengembangan, desain kami sepenuhnya Safety-I: pemindaian barcode, verifikasi identitas, dialog konfirmasi bertingkat, kontrol akses berbasis peran.

Kemudian kami menjalankan simulasi skenario. Situasinya:

Tiga dari delapan stasiun medis dipaksa evakuasi secara bersamaan. Pada saat evakuasi, operasi berikut sedang berlangsung:

• Transfusi darah dengan persyaratan rantai pengawasan (chain of custody) yang ketat
• Operasi bedah aktif yang harus dihentikan dan dilanjutkan di tempat lain
• Obat-obatan dalam perjalanan antar stasiun yang perlu dialokasikan ulang

Sistem Safety-I kami menangani pemeriksaan individual dengan baik. Yang tidak bisa ditanganinya adalah keseluruhan situasi. Sistem mengasumsikan kondisi operasional yang stabil. Kenyataan memberikan kebalikannya.

Kami membutuhkan sesuatu yang tidak hanya mencegah kesalahan dalam kondisi normal, tetapi secara aktif membantu manusia berhasil dalam kondisi abnormal.

Empat Prinsip yang Kami Pelajari

1. Membuat Ketidakpastian Terlihat

Naluri dalam desain perangkat lunak adalah menyajikan informasi yang bersih dan percaya diri. Angka tanpa kualifikasi. Indikator status yang hijau atau merah, tidak pernah kuning.

Dalam skenario bencana, kepercayaan diri ini berbahaya. Jika data inventaris belum disinkronkan selama tiga hari, menampilkan jumlah terakhir yang diketahui seolah-olah itu terkini akan menghasilkan keputusan yang buruk. Seorang perawat mungkin melewatkan penghitungan fisik karena sistem menunjukkan ada 12 unit. Mungkin hanya ada 4.

xGrid menandai setiap titik data dengan metadata kesegaran (freshness metadata). Ketika sinkronisasi melewati ambang batas, antarmuka menampilkan penanda stale (usang). Ini bukan indikator kerusakan — ini adalah sinyal kejujuran. Ini memberitahu operator: "Angka ini mungkin salah. Verifikasi sebelum bertindak."

Sistem yang mengakui ketidakpastian lebih dapat dipercaya daripada yang menyembunyikannya. Pengguna belajar mempercayai sistem justru karena sistem memberitahu mereka kapan tidak boleh mempercayai datanya.

2. Degradasi yang Anggun, Bukan Serba Boleh

Ketika sistem memasuki mode darurat, perancang menghadapi dilema. Mengunci semuanya dan berisiko memblokir operasi kritis? Atau membuka semuanya dan berisiko kesalahan?

Kebanyakan sistem memilih satu ekstrem. xGrid tidak memilih keduanya.

Dalam mode darurat, kami menghilangkan input yang tidak esensial. Kolom alamat, nomor asuransi, dokumentasi alergi terperinci — semuanya bisa dilewati. Tetapi tiga langkah konfirmasi tetap wajib terlepas dari status sistem:

• Verifikasi identitas pasien
• Konfirmasi nama dan dosis obat
• Verifikasi uji silang produk darah (cross-match)

Filosofi desainnya: manusia di bawah tekanan secara alami akan melewati langkah-langkah. Itu bukan cacat perilaku — itu adaptasi. Tugas sistem adalah membiarkan mereka melewati langkah yang bisa ditunda sambil memastikan mereka tidak bisa melewati langkah yang tidak bisa ditunda.

3. Merancang Catatan untuk Pembelajaran, Bukan untuk Menyalahkan

Setiap serah terima dalam xGrid menghasilkan catatan. Setiap pengeluaran obat, setiap transfer, setiap pergerakan inventaris. Data cukup terperinci untuk merekonstruksi seluruh linimasa kejadian.

Tetapi kami merancang sistem pencatatan dengan tujuan spesifik yang kebanyakan sistem audit lewatkan: belajar dari keberhasilan, bukan hanya dari kegagalan.

Pertimbangkan: setelah evakuasi yang berjalan sangat lancar, catatan menunjukkan bahwa seorang perawat telah secara proaktif memindai data produk darah ke ponselnya tiga menit sebelum perintah evakuasi datang. Ini tidak ada dalam protokol mana pun. Ini adalah improvisasi. Dan ini menghemat lima belas menit pemindaian ulang di stasiun penerima.

Safety-I tidak akan pernah menemukan ini, karena Safety-I hanya menyelidiki ketika sesuatu berjalan salah. Safety-II menyelidiki secara rutin, karena penyebab keberhasilan sama berharganya untuk dipahami seperti penyebab kegagalan. Improvisasi perawat tersebut kini menjadi bagian dari alur kerja yang direkomendasikan.

4. Menyediakan Jalur Resmi untuk Melanggar Aturan

Pengeluaran obat normal: dokter meresepkan, apoteker memverifikasi, perawat mengonfirmasi, obat dikeluarkan. Tiga gerbang kontrol. Safety-I yang solid.

Kenyataan bencana: dokter sedang triase dua puluh pasien. Apoteker di stasiun lain. Seorang pasien mengalami perdarahan. Perawat membutuhkan obat hemostatik sekarang.

Jika sistem berkata "tanpa resep, tanpa pengeluaran", perawat akan menemukan jalan lain — catatan kertas, perintah lisan, akses langsung ke lemari obat. Obat diberikan. Sistem tidak mencatat apa pun.

xGrid menawarkan penggantian darurat 24 jam (break-glass override). Perawat dapat mengaktifkan otorisasi darurat. Sistem mencatat tindakan tersebut, menandainya sebagai diotorisasi darurat, dan menandainya untuk ditinjau. Operasi berlanjut dengan jejak audit yang lengkap.

Ini bukan melewati keamanan. Ini adalah fitur keamanan. Hal paling berbahaya yang dapat dilakukan sistem adalah memaksa orang bekerja di luarnya, karena saat itu Anda kehilangan semua visibilitas. Pelanggaran aturan yang sah dan tercatat jauh lebih aman daripada solusi alternatif yang tidak terlihat.

Bukti: Patient I

Suite pengujian E2E kami mencakup Patient I — Uji Konsolidasi (Consolidation Test). Dirancang untuk menguji batas.

Pengaturan: 8 stasiun, 3 dipaksa evakuasi bersamaan. Selama evakuasi:

• Transfusi darah aktif (rantai pengawasan harus dipertahankan)
• Operasi bedah berlangsung (harus dihentikan, didokumentasikan melalui serah terima ISBAR, ditransportasi, dilanjutkan)
• Obat dalam perjalanan antar stasiun (harus dialokasikan ulang ke stasiun yang bertahan)

Hasil:

Verifikasi	Hasil
Identitas pasien terjaga selama transfer antar stasiun	Lulus
Rantai pengawasan darah dipertahankan, uji silang di stasiun baru	Lulus
Operasi dilanjutkan dengan catatan serah terima ISBAR lengkap	Lulus
Inventaris direkonsiliasi di semua stasiun yang digabungkan	Lulus
34 langkah dieksekusi, 34 lulus, nol kehilangan data	Lulus

Inilah Safety-II dalam praktik. Skenarionya bukan "mencegah evakuasi" — itu tidak mungkin. Skenarionya adalah "membuat evakuasi berhasil". Setiap titik data bertahan. Setiap serah terima tercatat. Setiap gerbang keamanan bertahan di mana perlu, dan mengalah di mana harus.

Pelengkap, Bukan Pengganti

Safety-II tidak menentang penghalang. xGrid tetap memiliki pemindaian barcode, verifikasi identitas, pemeriksaan dosis, kontrol akses berbasis peran. Mekanisme Safety-I ini mencegah kesalahan yang dapat dicegah.

Safety-II menangani semua yang lain — kasus di mana kondisi terlalu terdegradasi untuk prosedur normal, di mana protokol mengasumsikan sumber daya yang tidak Anda miliki, di mana jawaban buku teks tidak sesuai dengan situasi di hadapan Anda.

Dalam lingkungan yang stabil, Safety-I biasanya sudah cukup. Dalam lingkungan bencana, Safety-I diperlukan tetapi tidak cukup.

Tembok akan jebol. Pertanyaan yang penting adalah apa yang terjadi setelahnya.

---

Terkait: Uji Walkaway — Merancang Perangkat Lunak yang Bertahan Lebih Lama dari Penciptanya

---

Referensi

1. Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI