Nurse Call dan Code Blue: Alarm yang Bisa Diandalkan

Tombol panggilan perawat memanggil perawat; code blue memberi tanda keadaan darurat medis sesuai prosedur rumah sakit. Sistemnya harus mencatat panggilan, memastikan petugas menerimanya, dan tetap memberi tanda saat jaringan gagal. Artikel teknis ini membahas pengiriman pesan, jalur cadangan, serta pengujian gangguan. Target respons dan aturan penutupan panggilan perlu disepakati dengan tim rumah sakit.

Sistem tombol panggilan tidak cukup memakai jalur telemetri biasa. Demonstrasi yang lancar belum membuktikan satu penekanan penting akan tersimpan dan diterima petugas saat koneksi terganggu.

Apa yang membedakan alarm dari telemetri?

Enam perbedaan berikut memengaruhi rancangan penerimaan, pencatatan, dan penanganan panggilan.

Ketiadaan pesan harus dapat dibedakan dari koneksi yang gagal. Bangsal yang tenang dan jaringan yang mati dapat menghasilkan tampilan sama jika sistem tidak memantau kesehatan jalur komunikasi. Jalur kedua dan supervisi membantu membedakan kondisi tersebut.

Seberapa cepat sistemnya harus bekerja?

Cukup cepat sampai porsi sistem nyaris tak terasa di dalam jendela klinis, bukan ikut memakan jatah jendela itu. Artikel edukasi pada situs Kementerian Kesehatan menyebut harapan waktu kedatangan tim code blue 5 sampai 10 menit untuk sampai ke lokasi (Kemenkes, 8 Agustus 2022). Artikel tersebut bukan peraturan target respons nasional; sepakati ketentuan klinis dan akreditasi yang berlaku bersama rumah sakit.

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 setelah penyesuaian berkisar 2,4% sampai 50,9% antarrumah sakit. Rumah sakit di kuartil terbaik memiliki odds pasien selamat sampai pulang 41% lebih tinggi dibanding kuartil terbawah (OR 1,41; CI 95% 1,11–1,77). Studi itu menemukan sebagian besar variasi belum dijelaskan oleh faktor rumah sakit tradisional; studi tersebut tidak membuktikan satu penyebab tunggal.

Berikut usulan anggaran rekayasa untuk diuji bersama tim rumah sakit, bukan target klinis atau angka sertifikasi universal:

Anggaran teknis pada tiga tahap pertama perlu diuji oleh tim pengembang. Waktu eskalasi serta penutupan panggilan mengikuti prosedur klinis yang disepakati rumah sakit.

Mengapa tekan tombol bukan berarti menelepon?

Karena telepon bisa sibuk, dan penekanan tombol tidak boleh. Modelkan penekanan sebagai catatan panggilan yang siklus hidupnya lepas dari sesi suara mana pun. Sesi suara hanya salah satu bentuk respons terhadap catatan panggilan, bukan catatan panggilannya sendiri.

Pemisahan catatan panggilan dari sesi suara menghasilkan tiga aturan penting berikut.

Tidak ada yang pernah mendapat nada sibuk. Dua kamar menekan bersamaan menghasilkan dua catatan panggilan 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 catatan panggilannya. 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 catatan panggilannya. Kalau sesi suara berakhir dengan cara selain backend yang memerintahkan, catatan panggilan 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.

Syarat pengiriman minimal satu kali

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

MQTT QoS 1 memakai mekanisme pengiriman minimal satu kali pada jalur protokol yang dikonfigurasi, sehingga duplikat harus diantisipasi. Berikan ID tetap pada setiap penekanan dan buat penerimaan idempoten. Jika pesan dikirim ulang, backend mengirim konfirmasi kembali dengan ID panggilan yang sama. Perangkat kemudian dapat mengetahui bahwa panggilan sudah tercatat dan menghentikan pengiriman ulang.

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

Antrean lokal itu wajib ditulis sebelum percobaan kirim pertama, di semua mode — normal maupun degraded. Desain yang menggoda: baru menulis ke antrean setelah jaringan gagal. Itu menyisakan jendela 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 kejadian, 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 kejadian baru, naikkan gangguan yang persisten, tampilkan pola kesalahan di perangkat, dan tetap bunyikan konfirmasi dan nyalakan lampu jalur kabelnya.
• Kejadian yang dikirim ulang membawa umurnya, atau mengaku tidak tahu. Simpan waktu kejadian 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 nilai umur itu tidak valid — hapus perkiraan umurnya, pertahankan kejadian, lalu tandai catatan panggilannya "waktu tidak diketahui" daripada menebak. Ini kelas masalah yang sama dengan clock drift di sistem lapangan, dan di log code blue, waktu kejadian adalah buktinya.

Mengapa 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 panggilan perawat berjalur tunggal akan ikut gelap bersama semuanya.

Jalur kedua harus sederhana, terpisah secara fisik, dan tidak bergantung pada komponen yang sama dengan jalur utama.

Call line berkabel itu hanya 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, satuan 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. Jalur ini tetap membutuhkan catu daya dan perangkat keras yang berfungsi. Uji kegagalan daya bersama, kabel, dan komponen yang masih dipakai kedua jalur.

Ini juga alasan kenapa "mode darurat telepon keluar" di dalam satuan biasanya jawaban yang salah. Kalau server suara, broker, dan backend berbagi satu host — dan di penerapan LAN satu server memang begitu — maka host yang mati membawa serta jalur pengganti-nya. Jalur pengganti yang mati bersama hal yang dilindunginya bukan jalur pengganti. 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?

Hak penutupan mengikuti jenis panggilan dan prosedur yang berlaku. Sistem tidak boleh menyimpulkan panggilan selesai hanya karena sambungan suara berakhir.

DIN VDE 0834, standar Jerman untuk sistem panggilan perawat 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. Catatan panggilan 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 biasa di sisi tempat tidur, izinkan pembatalan oleh pasien hanya bila prosedur rumah sakit dan standar yang berlaku membolehkannya. Rancang gesturnya supaya tidak mudah terpicu saat 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?

Awasi tiap segmen jalur dan perlakukan ketiadaan sinyal kesehatan sebagai gangguan. UL 1069 membahas peralatan pensinyalan rumah sakit dan panggilan perawat; katalog ANSI mencantumkan Edisi 8, 2024. Batas 90 detik untuk sinyal gangguan komunikasi berasal dari pemberitahuan Intertek yang lebih lama. Periksa edisi dan ketentuan yang berlaku sebelum memakai angka itu sebagai dasar sertifikasi; sinyal gangguan juga harus dapat dibedakan dari 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. Keepalive 15 detik dapat mempercepat deteksi broker, tetapi uji seluruh jalur sampai sinyal gangguan, termasuk deteksi backend dan notifikasinya.

Matriks supervisi yang layak dicontek:

Baris tebal itu yang paling sering dilupakan tim. Di arsitektur ini aplikasi perawat tidak pernah menelepon 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, dasbor pos perawat tampil hijau semua dan aplikasinya baru diketahui tuli persis saat pasien menekan tombol.

Dua mekanisme tambahan membantu memeriksa kesiapan jalur:

Pemantauan tanda hidup backend. Perangkat yang hanya memeriksa broker belum mengetahui apakah backend juga bekerja. Gunakan pesan tanda hidup (liveness) yang disimpan broker sebagai pesan terakhir (retained) dan diperbarui setiap sepuluh detik. Perangkat memeriksa usianya untuk menentukan kapan masuk mode dengan fungsi terbatas (degraded).

Mode uji. Latihan mengikuti SOP rumah sakit. Sistem tanpa mode uji akan diuji menggunakan kejadian asli — mengotori data waktu respons yang justru dipakai saat penilaian akreditasi — atau tidak pernah diuji sama sekali. Perangkat darurat yang jarang dipakai dan tidak pernah diuji baru diketahui rusak saat keadaan darurat.

Rancangan yang mendukung pekerjaan perawat

Rancangan perlu memperhitungkan pekerjaan perawat, termasuk beban alarm. Dalam survei 3.986 perawat pada 213 rumah sakit, 76% melaporkan penundaan respons alarm dan 55% pernah menemui pasien yang membutuhkan bantuan mendesak tanpa petugas datang (Ruppel dkk., BMJ Open Quality, 2023). ECRI 2026 juga menempatkan implementasi teknologi yang memicu alur klinis tidak aman pada 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 tombol darurat, dengan pengatur waktu mengikuti SOP code blue rumah sakit.
3. Urutkan antrean berdasarkan prioritas, bukan hanya waktu datang. Panggilan kamar mandi di atas panggilan bedside, selalu terlihat, tidak pernah tertutup modal.
4. Setiap alarm punya pemilik. Catatan panggilan 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.

Daftar pemeriksaan 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. Bunyi konfirmasi terdengar; lampu lokal dan koridor tetap menyala.
• Matikan backend tetapi biarkan broker hidup. Unit wajib masuk mode degraded dalam jendela supervisi, dan menampilkan gangguan secara jelas.
• Pulihkan jaringan. Semua penekanan yang mengantre dikirim ulang dengan umur yang benar, dan penekanan yang melewati reboot satuan datang dengan tanda "waktu tidak diketahui", bukan waktu kejadian karangan.
• Kirim id kejadian yang sama dua kali. Satu catatan panggilan, dua konfirmasi, ID panggilan yang sama di keduanya.
• Batalkan panggilan kamar mandi sebagai pasien. Harus ditolak.
• Akhiri sesi suara kamar mandi secara normal. Catatan panggilan harus tetap terbuka dan lampu harus tetap menyala.
• Force-quit aplikasi pos perawat. 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.

Rancangan ini memakai pemantauan dan peringatan sistem dengan asumsi yang lebih ketat: tidak adanya pesan belum membuktikan jalur sehat. Perbedaan utama sistem panggilan bantuan terletak pada pencatatan, konfirmasi petugas, supervisi, dan perilaku saat terjadi kegagalan.