Cara Setup Notifikasi dan Tracking Status Surat Real-Time untuk RS & Klinik

Bayangkan rumah sakit tipe B dengan 40 unit kerja menerima 300–450 surat masuk per bulan. Tanpa sistem tracking, sekretariat mencatat di buku agenda, lalu staf menelepon unit lain untuk memastikan surat sudah diterima atau belum. Akibatnya disposisi tertunda rata-rata 2–4 hari, dan sekitar 5–8% surat tidak terlacak sama sekali. Di klinik dengan 10–15 karyawan, masalahnya lebih sederhana tapi tetap sama: surat izin operasional dari Dinas Kesehatan bisa tertahan berminggu-minggu hanya karena tidak ada yang tahu siapa pemegang terakhir dokumen tersebut. Artikel ini membahas cara membangun sistem notifikasi dan tracking status surat real-time yang ringan — cukup VPS 2 vCPU/4 GB RAM — dan tetap bisa terhubung dengan e-office yang sudah berjalan.

Arsitektur Event-Driven: Jangan Andalkan Polling

Pendekatan pertama yang biasanya dipilih adalah polling: dashboard memanggil API setiap 30 detik untuk mengecek status. Hitungannya cepat membengkak. Dengan 50 pengguna aktif dan interval 30 detik, server menerima 50 × 120 = 6.000 request per jam, atau 144.000 request per hari hanya untuk menanyakan ‘ada perubahan atau tidak’. Sebagian besar request itu mengembalikan hasil kosong. Beban ini memang masih tertahan di server modern, tapi biaya bandwidth, beban database, dan konsumsi baterai perangkat mobile menjadi tidak masuk akal.

Solusinya adalah event-driven dengan publish-subscribe. Setiap aksi — surat diterima, didisposisi, diproses, selesai, atau ditolak — ditulis ke tabel letter_events sekaligus dipublikasikan ke channel Redis. Klien tidak lagi bertanya; server yang memberi tahu. Kombinasi paling praktis untuk kebutuhan e-office adalah Laravel 11 untuk API dan panel admin, Redis 7.2 sebagai message broker, dan Socket.IO 4.7.1 di sisi klien web bila Anda ingin fallback ke long-polling otomatis saat WebSocket diblokir proxy kantor.

Skema minimalnya cukup tiga tabel: letters (id, nomor, perihal, pengirim, status, unit_id, deadline), letter_events (id, letter_id, status_lama, status_baru, actor_id, created_at, ip, user_agent), dan subscriptions (user_id, channel). Dengan skema ini Anda sudah mendapat audit trail lengkap tanpa tabel tambahan, dan bisa menurunkan laporan SLA dari data yang sama.

Satu catatan penting: publikasikan event setelah transaksi database commit, bukan di dalamnya. Gunakan event listener Laravel dengan ShouldQueueAfterCommit atau hook afterCommit() di koneksi. Kalau tidak, worker bisa mengirim notifikasi WhatsApp untuk surat yang transaksinya ternyata rollback — kesalahan klasik yang sulit dilacak di produksi.

Implementasi Worker Notifikasi Multi-Channel

Jangan kirim notifikasi di dalam request HTTP. Proses HTTP harus selesai di bawah 300 ms, sementara panggilan ke WhatsApp Business API atau SMTP bisa memakan 1–3 detik dan gagal sesekali. Pisahkan ke worker terpisah yang subscribe ke Redis dan mengirim notifikasi secara asinkron. Berikut contoh worker minimal dengan Node.js 20 LTS dan ioredis 5.4.1 yang mengirim pesan WhatsApp via Fonnte (bisa diganti Wablas atau WhatsApp Cloud API resmi).

// worker-notif.js — Node.js 20 LTS, ioredis 5.4.1
import Redis from 'ioredis';
import axios from 'axios';

const sub = new Redis(process.env.REDIS_URL);
await sub.subscribe('letter:events');

sub.on('message', async (_, raw) => {
  const evt = JSON.parse(raw); // {id, status, unit, phone, actor}
  await axios.post('https://api.fonnte.com/send', {
    target: evt.phone,
    message: `Surat ${evt.id} berstatus '${evt.status}' oleh ${evt.actor}.`
  }, { headers: { Authorization: process.env.FONNTE_TOKEN } });
});

Jalankan worker ini dengan pm2 atau systemd, bukan nodemon. Unit systemd dengan Restart=always dan RestartSec=5 membuat worker otomatis hidup kembali setelah crash atau deploy. Untuk volume 500–1.000 notifikasi per hari, satu worker dengan memori 256 MB cukup; naikkan ke dua replika bila latensi antrean melewati 30 detik.

Multi-channel bukan sekadar menambah integrasi. Terapkan aturan routing: WhatsApp untuk disposisi dan approval (dibaca dalam hitungan menit), email untuk laporan harian dan arsip (butuh jejak formal), serta push web untuk pengingat SLA. Simpan status pengiriman di tabel notification_logs (channel, status, error, sent_at) agar ketika pengguna mengeluh ‘tidak dapat notifikasi’, Anda punya bukti konkret — bukan spekulasi.

Untuk lingkungan RS dan klinik, perhatikan juga UU PDP. Nomor telepon dan isi perihal surat adalah data pribadi. Jangan kirim perihal lengkap di WhatsApp; cukup nomor surat, status, dan tautan ke sistem dengan autentikasi. Ini menekan risiko kebocoran saat perangkat hilang atau nomor berpindah tangan.

Timeline Tracking dan Eskalasi SLA Otomatis

Tracking yang berguna bukan sekadar kolom status, tapi kronologi. Tampilkan timeline vertikal: siapa yang menerima, kapan didisposisi, ke unit mana, catatan disposisi, dan berapa lama surat berada di tiap unit. Data ini datang dari letter_events yang sudah Anda tulis di bagian sebelumnya — tidak perlu tabel baru.

Eskalasi SLA dijalankan sebagai cron job setiap 15 menit. Aturan contoh: surat berstatus diproses lebih dari 3 hari kerja → kirim pengingat ke pemegang; lebih dari 5 hari → eskalasi ke atasan unit; lebih dari 7 hari → masukkan ke daftar harian Kepala Bagian Umum. Query-nya cukup satu SELECT dengan index pada (status, updated_at). Di MySQL 8, index komposit ini membuat pemindaian 200.000 baris selesai di bawah 50 ms.

Di sisi UI, gunakan komponen ringan. Alpine.js 3.14 atau Livewire 3 sudah cukup untuk merender timeline reaktif tanpa membangun SPA penuh. Bila tim Anda memakai React, pakai TanStack Query 5 untuk caching dan refetch on focus; ini menghilangkan 80% kebutuhan state management manual.

Untuk petugas lapangan yang mengambil surat fisik di ruang arsip, sediakan tombol scan QR di halaman mobile. Setiap QR memuat UUID surat; sekali scan, event ‘diterima’ tercatat beserta timestamp dan GPS opsional. Waktu pencatatan turun dari 30–45 detik menjadi di bawah 5 detik per surat.

Best Practices

1. Commit dulu, publish kemudian. Gunakan afterCommit agar event tidak terkirim untuk transaksi yang rollback.
2. Idempoten. Simpan event_id di notification_logs dengan unique index; worker yang menerima pesan ganda tidak mengirim notifikasi dua kali.
3. Batasi payload. Maksimal 4 KB per event — kirim ID dan tautan, bukan isi dokumen atau perihal lengkap.
4. Retensi terukur. letter_events disimpan 24 bulan, dipartisi per bulan agar DELETE cepat dan index tetap ramping.
5. Uji kegagalan, bukan hanya happy path. Simulasikan Redis down, gateway timeout 30 detik, dan token kedaluwarsa minimal sekali sebelum go-live.

FAQ

Apakah WebSocket wajib? Bisa pakai Server-Sent Events?

Tidak wajib. SSE (EventSource) cukup untuk notifikasi satu arah dan lebih sederhana di balik reverse proxy Nginx. WebSocket unggul bila Anda butuh kanal dua arah, misalnya kolaborasi disposisi antar unit. Untuk e-office, SSE dengan heartbeat 25 detik sudah memadai dan hemat memori server.

Berapa perkiraan biaya infrastruktur bulanan?

VPS 2 vCPU/4 GB RAM di penyedia lokal sekitar Rp 150–250 ribu/bulan, Redis self-hosted gratis, dan WhatsApp gateway Rp 150–400 ribu/bulan tergantung volume. Total di bawah Rp 700 ribu/bulan untuk 50–100 pengguna aktif — jauh lebih murah dari satu kesalahan disposisi yang tertunda berhari-hari.

Bisa diintegrasikan dengan e-office yang sudah berjalan?

Bisa. Umumnya cukup menambahkan webhook di sisi e-office yang memanggil endpoint /api/events setiap status berubah. Bila vendor tidak menyediakan webhook, opsi kedua adalah CDC (change data capture) dengan Debezium 2.6 membaca binlog MySQL, atau polling terjadwal 5 menit khusus untuk tabel status.

Bagaimana kalau koneksi internet kantor mati?

Notifikasi WhatsApp tetap terkirim karena worker berjalan di VPS, bukan di jaringan kantor. Yang terganggu hanya akses dashboard. Sediakan mode degradasi: halaman status terakhir tetap terbuka lewat cache PWA (service worker) sehingga petugas masih melihat snapshot terakhir.

Membangun tracking surat real-time tidak memerlukan stack mahal. Tiga komponen inti — event log, message broker, dan worker notifikasi — sudah cukup untuk memangkas waktu disposisi dari hari menjadi menit. Kunci keberhasilannya bukan pada teknologi, tapi pada disiplin mencatat setiap perubahan status dan menguji jalur kegagalan sebelum go-live. Jika Anda mengelola RS, klinik, atau kantor operasional di Yogyakarta (DIY) dan Magelang yang ingin mengintegrasikan tracking surat dengan SIMRS, SIM Klinik, ERP, POS, atau e-office yang sudah ada, tim kami menyediakan layanan konsultasi IT dan pengembangan aplikasi custom yang disesuaikan dengan alur kerja Anda.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: SIMRS SIM Klinik E-Office. Butuh konsultasi gratis?