Ketika Aplikasi SIMRS Error Tepat Saat Jam Puncak Antrean Poli Pagi

Ketika Aplikasi SIMRS Error Tepat Saat Jam Puncak Antrean Poli Pagi

Jam 07.00 pagi di rumah sakit, ruang pendaftaran sudah kayak stasiun Tanah Abang habis Lebaran. Sobat IT RS pasti udah hafal: printer antrian mulai ngebul, petugas loket ketik data pasien secepat jari-jari setan, dan suara panggilan antrian silih berganti. Tiba-tiba, SIMRS ngadat. Loading muter-muter, form entry enggak respon, pasien mulai teriak, petugas panik, kepala ruangan nelpon ke IT: “Mas, ini SIMRS kenapa?! Cepat dibenerin! Sudah banyak pasien nunggu!”

Panikan? Sudah pasti. Tapi bukan saatnya panik—saatnya refleksi bareng, bagaimana Sobat IT RS bisa bertahan, koordinasi secepat kilat, dan evaluasi supaya besok-besok enggak keulang. Ini cerita nyata. Siapkan kopi, kita bedah bareng!

Bagaimana Krisis Dimulai: Skenario Jam Puncak Poli

Rangkaian Kejadian

  • Jam 07:05: SIMRS (modul pendaftaran) mulai lemot, user mengeluh lambat respon.
  • Jam 07:10: Login semua user baru gagal, yang sudah login formnya freeze.
  • Jam 07:15: Printer antrian enggak bisa cetak tiket. Petugas mulai tulis tangan nomor antrian.
  • Jam 07:20: Kepala ruang pendaftaran telpon IT, laporan kondisi dan desak perbaikan cepat.
  • Jam 07:30: IT turun ke lokasi, cek server & jaringan, cari sebab utama.

Kenapa Sering Terjadi di Jam Pagi?

  • Puncak load trafik: Semua pasien datang barengan, 70% pendaftaran harian terjadi antara jam 07:00-09:00.
  • Batch job malam kadang masih jalan (backup DB, sync data, report harian), makan resource server.
  • Petugas shift pagi sering baru login serempak, trigger spike session/database connection.
  • Manajemen pasien BPJS vs umum, sistem validasi peserta BPJS sering delay pagi hari (API eksternal lambat).

Langkah Darurat: Mitigasi di Lapangan

Koordinasi Cepat Antar Tim

  • Petugas pendaftaran: Segera alihkan ke proses manual (tulis tangan nomor antrian, catat data pasien di kertas/form Excel, input nanti setelah SIMRS pulih).
  • IT Support: Cek status server dan jaringan (ping, CPU/RAM, status koneksi DB, traffic switch/router), langsung di lokasi bukan remote (biar tahu kondisi user & hardware real-time).
  • Koordinasi ke Kepala Ruangan: Update rutin status perbaikan, pastikan info jelas agar tidak simpang siur ke pasien/pimpinan.
  • Backup komunikasi: Siapkan WA group/Telegram khusus tim krisis, update real-time tanpa harus ke lokasi semua.

Checklist Mitigasi Cepat

  • Identifikasi dulu sumber masalah:
    • DB down? Cek koneksi SQL Server/PostgreSQL (pakai sqlcmd atau psql langsung dari server).
    • Overload CPU/RAM? Cek via top atau task manager (Windows Server).
    • Jaringan putus? Ping gateway, traceroute ke server.
    • Satu modul atau seluruh aplikasi? User beda ruangan kena efek sama/tidak.
  • Sediakan opsi input manual sementara: Form Excel, kertas, atau aplikasi offline (bila punya backup desktop/lokal).
  • Prioritaskan pemulihan fungsi minimum: Kalau SIMRS belum full up, minimal modul pendaftaran dulu.
  • Update user tiap 5-10 menit: Supaya user tahu progres, enggak tambah panik.

Penyebab Umum SIMRS Error Saat Jam Pagi

1. Overload Database Connection

Contoh kasus:

Pagi hari, ada 30 user daftar serentak, aplikasi web pakai connection pool default (max 20), sisa user nunggu slot kosong. User lihat loading muter-muter, timeout, error timeout expired.

Struktur connection pool (contoh SQL Server, file web.config):

<connectionStrings>
  <add name="SIMRS_DB" 
    connectionString="Server=10.10.10.1;Database=simrs;User Id=simrs;Password=rahasia;Max Pool Size=20;" 
    providerName="System.Data.SqlClient" />
</connectionStrings>

Fix cepat: Naikkan Max Pool Size ke 50 atau 100 (lihat kapasitas RAM & DB), restart aplikasi.

2. Query Lambat/Macet (Slow Query)

  • Query modul pendaftaran cek peserta BPJS, join tabel besar tanpa index: tiap request makan waktu >5 detik.
  • Batch report jalan pagi hari (cron/SQL Agent), locking table transaksi, user lain nunggu.

Contoh query biang kerok:

SELECT p.nama, k.tgl_kunjungan
FROM pasien p
JOIN kunjungan k ON p.no_rm = k.no_rm
WHERE k.tgl_kunjungan = CURRENT_DATE
AND EXISTS (SELECT 1 FROM bpjs WHERE bpjs.no_kartu = p.no_kartu)
ORDER BY p.nama

Lambat karena EXISTS tanpa index di bpjs.no_kartu. Solusi: tambahkan index, cek explain plan.

3. Resource Server Kepenuhan

  • Backup database (schedule malam) belum selesai, nyedot IOPS/CPU, SIMRS jalan bareng jadi lemot.
  • Antivirus update/scan pagi hari, makan RAM/CPU.

Langkah:

  • Reschedule backup ke dini hari (jam 01.00-03.00), pastikan selesai sebelum jam operasional.
  • Cek jadwal task Windows/Linux (Task Scheduler, cron), atur ulang jika bentrok.

4. Masalah Jaringan Lokal

  • Switch core overload atau port error (light blinking abnormal), broadcast storm, packet loss.
  • Wifi drop, user pakai kabel LAN lebih stabil pagi hari.

Cek dengan ping dan tracert:

ping 10.10.10.1 -t
tracert 10.10.10.1

Kalau latency loncat >10ms atau banyak "Request timed out", cek kabel, switch, restart port.

5. API BPJS Down/Lambat

Sering banget pagi hari, traffic ke API VClaim BPJS naik, respons delay atau timeout. Modul pendaftaran nunggu respons, satu form hang semua.

Perlu fallback: jika API BPJS delay, simpan data pasien sebagai "pending", lanjut input, urusan validasi nanti begitu API up.

Studi Kasus Lapangan: Kronologi Penanganan

Kasus Error Modul Pendaftaran Poli (SQL Server Connection Limit)

  1. Jam 07:00, user mulai login dan entry data, tiba-tiba aplikasi freeze.
  2. IT cek server, CPU/RAM normal, tetapi found banyak error di SQL Server log: 
    System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool.
  3. CEK: sys.dm_exec_connections di SQL Server: 
    SELECT COUNT(*) FROM sys.dm_exec_connections WHERE session_id > 50;

    Ketemu: active connection sudah 20 (limit pool). Sisa user nunggu, timeout, dapat error.

  4. FIX: Edit web.config aplikasi, Max Pool Size jadi 80, restart app pool.
  5. Recovery: User login ulang, aplikasi lancar. Modul lain (farmasi, kasir) ikut normal.
  6. Evaluasi: Cek query slow, audit session leak, tambahkan monitoring pool DB.

Kasus Error Karena Query Lambat (PostgreSQL)

  1. Jam 07:10, user modul poli dan kasir ngeluh lemot, kadang timeout.
  2. IT remote ke server, cek pg_stat_activity: 
    SELECT state, query 
FROM pg_stat_activity 
WHERE state != 'idle';

    Ketemu query join tabel pasien & kunjungan tanpa index, sudah jalan 280 detik, status active.

  3. EXPLAIN query, lihat Seq Scan di bpjs, artinya belum ada index.
  4. FIX: Tambah index: 
    CREATE INDEX idx_bpjs_no_kartu ON bpjs(no_kartu);

    Kill session runaway, restart aplikasi.

  5. Recovery: Query jadi 3x, kirim alert.
  6. Dashboard resource (pakai Grafana + Prometheus, atau Zabbix, atau Nagios, atau tool gratisan lain).
  7. Log error aplikasi ke Google Spreadsheet (pakai script integrasi sederhana), bisa diakses semua tim.

    8. Contoh Script Monitoring Pool SQL Server (Powershell)

    # File: cek_pool.ps1
$server = "localhost"
$database = "simrs"
$query = "SELECT COUNT(*) as cnt FROM sys.dm_exec_connections WHERE session_id > 50"
Invoke-Sqlcmd -ServerInstance $server -Database $database -Query $query

    Jadwalkan lewat Task Scheduler, jika cnt mendekati limit, auto-email ke tim IT.

    Penutup: SIMRS Down Bukan Akhir Dunia, Tapi Harus Belajar Bareng

    Sobat IT RS, aplikasi SIMRS error di jam sibuk itu membumi, bukan aib. Yang penting: tim sigap, SOP jelas, teknis siap, komunikasi jalan. Setiap insiden jadi pelajaran, biar besok pagi kalau printer antrian ngebul lagi, kita sudah tahu harus ngapain. Jangan lupa, evaluasi bareng user itu wajib biar trust ke IT tetap naik.

    Sudah pernah ngalamin insiden lebih parah? Share pengalaman di kolom komentar petirs.id, atau kontak langsung MinTIRS buat diskusi teknis lebih dalem. Tetap santai, tetap ngopi, tetap waras di dunia SIMRS yang kadang “njelimet” ini!