Nurse Call dan Code Blue: Desain Alarm Kelas Nyawa

Nurse Call dan Code Blue: Desain Alarm Kelas Nyawa

Alarm kelas nyawa punya kontrak keandalan — daftar jaminan minimum yang wajib dipenuhi sistem — lebih ketat daripada telemetri, kiriman data pembacaan rutin dari perangkat. Telemetri boleh kehilangan satu sampel, boleh telat, boleh diam saat tidak ada apa-apa. Alarm tidak boleh satu pun. Yang dibutuhkan: batas latensi yang jelas, pengiriman at-least-once — minimal sekali sampai, walau bisa dobel — dengan dedup yang menyaring dobelnya, konfirmasi yang berujung ke manusia, jalur kedua yang hidup saat jalur pertama mati, dan supervisi yang membuktikan tiap ujung masih hidup sebelum dibutuhkan.

Kebanyakan platform IoT dibangun di atas kontrak telemetri, lalu diarahkan ke sebuah tombol. Di demo, mulus. Yang gagal justru satu penekanan yang paling penting.

Apa yang membedakan alarm dari telemetri?

Enam hal. Semuanya mengubah kode yang Anda tulis.

Dua baris terakhir yang memikul seluruh desain. Di telemetri, sunyi dan sehat terlihat sama persis, dan itu bisa diterima. Di sistem alarm, sunyi justru sinyal yang tidak boleh tertukar dengan bencana. Bangsal yang tenang dan jaringan yang mati menghasilkan dashboard yang identik. Menghapus ambiguitas itulah sebagian besar pekerjaan tekniknya.

Seberapa cepat sistemnya harus bekerja?

Cukup cepat sampai porsi sistem nyaris tak terasa di dalam jendela klinis, bukan ikut memakan jatah jendela itu. Kementerian Kesehatan menargetkan respon code blue 5 sampai 10 menit untuk sampai ke lokasi (Kemenkes, 8 Agustus 2022). Akreditasi rumah sakit menilai waktu respon yang terdokumentasi, bukan waktu respon yang diperkirakan.

Bukti klinisnya memasang batas yang jauh lebih ketat. Dari 7.479 kejadian henti jantung di 200 rumah sakit Amerika, 18,3% pasien menunggu defibrilasi lebih dari 2 menit (Chan dkk., Archives of Internal Medicine, 2009). Angka keterlambatan itu berkisar 2,4% sampai 50,9% antar rumah sakit. Rumah sakit di kuartil terbaik punya peluang pasien selamat sampai pulang 41% lebih tinggi (OR 1,41; CI 95% 1,11–1,77). Yang membedakan bukan ukuran atau status pendidikan rumah sakitnya, melainkan prosesnya.

Anggaran waktu itulah yang dibelanjakan sistem Anda. Pembagian yang masuk akal:

Semua yang di atas timer eskalasi pertama itu urusan teknik. Semua yang di bawahnya urusan prosedur klinis; jangan Anda karang sendiri.

Kenapa tekan tombol bukan berarti menelepon?

Karena telepon bisa sibuk, dan penekanan tombol tidak boleh. Modelkan penekanan sebagai ticket yang siklus hidupnya lepas dari sesi suara mana pun. Sesi suara cuma salah satu bentuk respon terhadap ticket, bukan ticket-nya sendiri.

Tiga akibat langsung lahir dari pemisahan itu. Tanpa pemisahan, ketiganya jadi bug yang lolos ke production.

Tidak ada yang pernah mendapat nada sibuk. Dua kamar menekan bersamaan menghasilkan dua ticket dalam satu antrean terurut. Desain berpola telepon akan membalas "saluran sibuk" ke pasien kedua — sistem yang menolak permintaan tolong.

Lampu konfirmasi tidak boleh berbohong. Dua tahap: kedip cepat berarti terkirim, kedip normal berarti terdaftar. Unit baru boleh menampilkan "terdaftar" setelah backend mengakui ticket-nya. Lampu yang menyala penuh hanya karena logika tombol lokal sedang memberi tahu pasien yang ketakutan bahwa bantuan sedang datang, padahal tidak ada apa pun yang keluar dari kamar itu.

Putus tidak normal membuka lagi ticket-nya. Kalau sesi suara berakhir dengan cara selain backend yang memerintahkan, ticket kembali ke NEW dengan tanda "terputus", bukan menutup diam-diam. Jangan menyimpulkan normal dari kode penyebab hangup — Asterisk 20 sampai 22 punya kasus cause kosong, dan cause kosong yang dibaca "normal" berarti menutup kegawatan yang masih berjalan.

Berapa mahal harga pengiriman at-least-once?

Tiga hal yang biasanya dilewat: id event yang idempoten, konfirmasi di level aplikasi, dan antrean lokal yang ditulis sebelum jaringan dicoba.

MQTT QoS 1 artinya minimal satu kali, jadi duplikat itu kepastian, bukan kemungkinan. Beri tiap penekanan id event yang stabil dan buat titik masuknya idempoten — pesan yang sama boleh masuk berkali-kali, hasilnya tetap satu ticket. Bagian yang sering hilang justru balasannya: duplikat wajib diakui ulang, dengan ticket id yang sama. Bukan ack kosong, bukan didiamkan. Unit tidak bisa membedakan "ini sudah saya punya" dari "ini tidak pernah sampai", jadi ia akan terus mengulang sementara pasien menatap lampu yang tak kunjung pasti.

PUBACK broker juga bukan konfirmasi. Ia cuma bilang broker menerima byte-nya. Ia tidak bilang apa-apa soal ada tidaknya ticket, dan backend bisa mati sementara broker sehat walafiat. Hanya balasan ticket-created di level aplikasi yang boleh menghapus entri antrean lokal.

Antrean lokal itu wajib ditulis sebelum percobaan publish pertama, di semua mode — normal maupun degraded. Desain yang menggoda: baru menulis ke antrean setelah jaringan gagal. Itu menyisakan jendela 8 sampai 10 detik antara penekanan dan pemicu mode degraded; satu brownout di jendela itu menghapus panggilan yang memang belum pernah tercatat di mana pun. Satu pemilik siklus hidup event, tanpa jalur pintas.

Dua aturan menjaga antrean itu tetap jujur:

• Penuh atau gagal tulis berarti fail loud, bukan buang yang paling tua. Entri tertua adalah panggilan yang paling lama tak terjawab — justru yang paling tidak boleh dibuang. Tolak event baru, naikkan fault yang persisten, tampilkan pola error di unit, dan tetap bunyikan beep serta lampu jalur kabelnya.
• Event yang di-replay membawa umurnya, atau mengaku tidak tahu. Simpan timestamp monotonik plus penghitung boot di tiap entri. Saat replay, kirim umurnya supaya backend bisa menghitung kapan tombol ditekan. Kalau penghitung boot berubah, unit sempat reboot, jam monotoniknya reset, dan umur itu bohong — buang, lalu tandai ticket-nya "waktu tidak diketahui" daripada menebak. Ini kelas masalah yang sama dengan clock drift di sistem lapangan, dan di log code blue, timestamp adalah buktinya.

Kenapa jalur kedua lebih penting daripada jalur pertama yang lebih bagus?

Karena kegagalan yang menyakitkan adalah yang menghabisi seluruh stack sekaligus. ECRI menempatkan "ketidaksiapan menghadapi digital darkness" sebagai bahaya teknologi kesehatan #2 untuk 2026 (terbit 21 Januari 2026), dan mendefinisikannya sebagai hilangnya akses ke sistem elektronik dan data pasien secara mendadak. Sistem nurse call berjalur tunggal akan ikut gelap bersama semuanya.

Jalur kedua tidak boleh jadi versi lebih pintar dari jalur pertama. Ia harus lebih bodoh dan terpisah secara fisik.

Call line berkabel itu cuma GPIO yang menarik driver lampu. Ia tidak butuh broker, tidak butuh backend, tidak butuh DNS, tidak butuh sertifikat. Server mati, jaringan mati, backend restart terus-menerus: pasien menekan, unit berbunyi, lampu koridor menyala, dan perawat yang lewat tahu kamar mana. Pengalamannya lebih buruk daripada sistem penuh, dan jauh lebih baik daripada tidak ada apa-apa.

Ini juga alasan kenapa "mode darurat telepon keluar" di dalam unit biasanya jawaban yang salah. Kalau server suara, broker, dan backend berbagi satu host — dan di deployment LAN satu server memang begitu — maka host yang mati membawa serta fallback-nya. Fallback yang mati bersama hal yang dilindunginya bukan fallback. Kerumitannya besar, padahal jendela yang dilindunginya sempit — dan restart policy container sudah menutup jendela itu dalam hitungan detik. Logikanya sama dengan titik kegagalan tunggal di sistem bisnis: redundansi bodoh yang murah biasanya menang atas redundansi pintar yang mahal.

Siapa yang berhak menutup sebuah alarm?

Bukan sistemnya, dan sering kali bukan pasiennya.

DIN VDE 0834, standar Jerman untuk sistem nurse call di rumah sakit dan panti rawat, tegas soal ini: panggilan tanpa kemampuan bicara hanya boleh dibatalkan di lokasi panggilan, dan kalau ada jalur bicara, pembatalan jarak jauh baru sah bila koneksi suara benar-benar terbentuk (ZVEI, Call Systems according to DIN VDE 0834). Ruangan yang tidak terlihat dari titik deteksi kehadiran — kamar mandi — wajib punya pembatalan panggilan sendiri.

Baca itu sebagai aturan desain, bukan formalitas Eropa. Aturan itu menutup satu mode kegagalan: perawat membuka kanal, tidak mendengar apa-apa, lalu menutup. Di kamar mandi, "tidak mendengar apa-apa" persis seperti bunyi pasien yang tergeletak di keramik. Karena itu panggilan kamar mandi dan pull-cord jadi kelas tersendiri sejak versi pertama:

• Tidak auto-resolve saat sesi suara berakhir. Ticket pindah ke AWAITING_CONFIRM dan lampu kamar tetap menyala.
• Penutupan hanya lewat aksi eksplisit perawat — "kamar sudah dicek" — tercatat lengkap dengan identitas perawat dan waktunya.
• Pasien tidak bisa membatalkan panggilan kamar mandi sama sekali. Hanya petugas.

Untuk panggilan bedside biasa, pembatalan oleh pasien tidak masalah, tapi rancang gesturnya supaya tahan panik. Tekan lama dua detik atau lebih untuk membatalkan; tekan pendek berulang diabaikan. Orang yang ketakutan pasti memencet berkali-kali, dan itu tidak boleh membatalkan permintaan tolongnya sendiri.

Bagaimana Anda tahu semua titik masih bekerja?

Dengan mengawasi tiap segmen jalur, dan memperlakukan sunyi sebagai gangguan. UL 1069, standar Amerika Utara untuk peralatan signaling rumah sakit dan nurse call (Edisi 8, 2024), memberi angka yang tegas: waktu maksimum dari munculnya fault di jalur komunikasi mana pun sampai sinyal trouble berbunyi adalah 90 detik, dan sinyal trouble itu wajib bisa dibedakan dari semua sinyal panggilan.

Sembilan puluh detik tetap patokan berguna walau instalasi Anda tidak disertifikasi, karena angka itu langsung mencoret desain malas yang paling umum. Keepalive MQTT 60 detik berarti last will baru terbit sekitar detik ke-90, dan logika alarm Anda baru mulai bekerja di situ. Set keepalive 15 detik, deteksinya masuk jendela dengan longgar.

Matriks supervisi yang layak dicontek:

Baris tebal itu yang paling sering dilupakan tim. Di arsitektur ini aplikasi perawat tidak pernah men-dial keluar — semua sesi diinisiasi backend — jadi registrasi suara aplikasi baru terpakai saat ada panggilan masuk. Socket datanya bisa kelihatan sehat-sehat saja sementara registrasi suaranya sudah mati, dan stack SIP di ponsel memang bisa kehilangan registrasi saat aplikasi di background. Tanpa baris itu, dashboard nurse station tampil hijau semua dan aplikasinya baru ketahuan tuli persis saat pasien menekan tombol.

Dua detail supervisi lain yang cepat balik modal:

Topic liveness backend yang di-subscribe unit. Unit yang cuma memantau koneksi brokernya sendiri tidak bisa membedakan "broker hidup, backend mati" dari kondisi sehat. Heartbeat retained dari backend, disegarkan tiap sepuluh detik, menutup celah itu dan membuat unit bisa pindah ke umpan balik degraded atas inisiatif sendiri.

Mode uji. Drill itu wajib di SOP hampir semua rumah sakit. Sistem tanpa mode uji akan di-drill pakai event asli — mengotori data waktu respon yang justru dipakai saat penilaian akreditasi — atau tidak pernah di-drill sama sekali. Perangkat darurat yang jarang dipakai dan tidak pernah diuji baru ketahuan rusak saat keadaan darurat.

Apa yang desain ini utang ke perawat yang jaga?

Lebih banyak daripada yang biasanya tercantum di diagram arsitektur. Dari survei 3.986 perawat di 213 rumah sakit, 76% mengaku menunda respon terhadap alarm dan 55% pernah menemui situasi pasien butuh pertolongan mendesak tanpa ada yang datang (Ruppel dkk., BMJ Open Quality, 2023). Daftar ECRI 2026 menyebut tema yang sama dari arah berlawanan, menaruh "implementasi teknologi kesehatan yang memicu alur kerja klinis tidak aman" di peringkat #9.

Sistem alarm yang menambah kebisingan membuat bangsal lebih berbahaya, bukan lebih aman. Empat aturan turunannya:

1. Bunyi berbeda untuk kelas berbeda. Panggilan kamar mandi dan peringatan baterai lemah tidak boleh berbagi nada. Kalau semua berbunyi sama, semua diperlakukan sama — artinya diperlakukan terlambat.
2. Naikkan tingkat, jangan mengulang. Mengulang alarm yang sama ke orang yang sama melatih orang itu mengabaikannya. Setelah timeout kebijakan, kirim ke orang lain — pola rantai eskalasi yang sama dengan fleet panic button, dengan timer mengikuti SOP code blue rumah sakit.
3. Urutkan antrean berdasarkan prioritas, bukan cuma waktu datang. Panggilan kamar mandi di atas panggilan bedside, selalu terlihat, tidak pernah tertutup modal.
4. Setiap alarm punya pemilik. Ticket yang sudah diklaim menampilkan siapa yang mengklaim, supaya dua perawat tidak sama-sama jalan ke kamar 3 sementara kamar 7 menunggu. Buat klaimnya atomik di backend; dua tap di detik yang sama harus menghasilkan satu pemenang.

Checklist sebelum sistemnya dinyatakan siap

Sebelum sistem alarm kelas nyawa dipakai, ini hal-hal yang layak dibuktikan lewat pengujian, bukan lewat diagram:

• Tekan tombol dengan kabel jaringan dicabut. Beep, lampu lokal, lampu koridor — ketiganya tetap menyala.
• Matikan backend tapi biarkan broker hidup. Unit wajib masuk mode degraded dalam jendela supervisi, bukan duduk manis kelihatan sehat.
• Pulihkan jaringan. Semua penekanan yang mengantre di-replay dengan umur yang benar, dan penekanan yang melewati reboot unit datang dengan tanda "waktu tidak diketahui", bukan timestamp karangan.
• Kirim id event yang sama dua kali. Satu ticket, dua konfirmasi, ticket id yang sama di keduanya.
• Batalkan panggilan kamar mandi sebagai pasien. Harus ditolak.
• Akhiri sesi suara kamar mandi secara normal. Ticket harus tetap terbuka dan lampu harus tetap menyala.
• Force-quit aplikasi nurse station. Tombol jawab harus mati dan alarm harus berbunyi dalam jendela supervisi.
• Jalankan drill di mode uji. Tidak ada satu pun jejak drill itu yang muncul di laporan kejadian.

Tidak ada yang aneh-aneh di sini. Semuanya cuma disiplin monitoring dan alerting biasa, dijalankan dengan asumsi bahwa sunyi tidak pernah berarti kabar baik. Yang membedakan sistem nurse call dari jaringan sensor bukan hardware-nya — board, broker, dan protokolnya sama saja. Yang membedakan adalah apa yang berani Anda asumsikan ketika tidak ada apa pun yang datang.