Gagal Kirim ke BPJS? SIMRS Gak Boleh Ikut Galau

🔀 Read in English 🇬🇧

Selamat Datang di Hajriah Fajar: Hidup Sehat & Cerdas di Era Digital

Gagal Kirim ke BPJS? SIMRS Gak Boleh Ikut Galau

Hari itu hujan. Koneksi internet mendadak loyo. Dan saat dokter selesai isi SOAP, muncul notifikasi yang bikin merinding: “Gagal Kirim ke BPJS”. Langsung satu ruangan riuh. “Data tadi masuk gak?” “SEP-nya udah terbit belum?” Dan yang paling absurd adalah: walaupun yang gagal cuma BPJS, SIMRS ikut-ikutan ngambek.

Kenapa SIMRS harus ikutan stres kalau BPJS-nya yang lemot?

Masalahnya: Semua Digabung Sekaligus

Banyak sistem SIMRS yang menaruh semua proses — simpan lokal, panggil API eksternal, insert ke antrean, generate SEP — dalam satu alur serentak. Jadi kalau satu aja macet (misalnya API VClaim timeout), yang lain juga gagal. Padahal logikanya simpel: kalau kirim surat ke Jakarta gagal, masa isi dokumen internal juga dibatalkan?

Pemisahan Proses: Lokal & Eksternal

Solusi utamanya: isolasi proses. Simpan dulu semua data ke database lokal. Tandai status eksternal (misal BPJS) sebagai "pending". Baru setelah itu, sistem background yang akan coba kirim ke BPJS pakai retry, delay, bahkan fallback.

Kenapa Harus Dipisah?

Alasan	Kalau Dipisah	Kalau Digabung
Kecepatan input user	Simrs tetap responsif	Lambat, nunggu BPJS
Stabilitas data	Data tetap aman di lokal	Berisiko gagal total
Retry otomatis	Bisa dilakukan background	Tidak bisa, harus manual

Retry Gak Boleh Overheat

Retry juga gak boleh asal spam. Pakai strategi retry seperti:

• Exponential backoff: jeda makin panjang tiap gagal
• Limit maksimal retry: misal 5x, lalu masuk log khusus
• Notifikasi error: kirim ke admin kalau gagal terus

Studi: Sistem Resilient API

Menurut studi dari Google SRE Book, sistem yang baik harus bisa “fail open” saat resource eksternal down. Artinya sistem tetap berjalan, sambil menunggu eksternal pulih.

Visualisasi Antrian Eksternal

Gunakan dashboard visual:

• Status kirim BPJS: pending / success / failed
• Jumlah antrean SEP yang belum berhasil
• Waktu terakhir retry

Penutup: SIMRS Harus Tahan Mental

BPJS down itu hal biasa. Tapi SIMRS yang ikut-ikutan galau? Itu bisa bahaya. Sistem yang sehat bukan yang sempurna, tapi yang tahu cara gagal dengan elegan. Pisahkan lokal & eksternal. Gunakan queue. Tampilkan status. Dan biarkan dokter tetap bekerja — walau kabel ke BPJS lagi melilit.

---

Welcome to Hajriah Fajar: Living Smart & Healthy in the Digital Age

BPJS Failed Again? Let SIMRS Stay Calm

It was raining. Internet was slow. The doctor just saved a SOAP note. Then came the scary message: “Failed to Send to BPJS”. But the worst part? Even SIMRS refused to continue.

Why should our hospital system go down just because BPJS is having a bad day?

The Real Problem: Everything Is Tied Together

Most SIMRS tie all processes — saving local data, calling external APIs, SEP generation — into one tight package. If one fails (say VClaim API times out), everything crashes. That’s like canceling a whole event because the guest speaker’s car broke down.

Separate Local and External Processes

Save data locally first. Flag external jobs (like BPJS) as pending. Then let background workers handle retries — no user involved.

Retry Smartly

• Exponential backoff
• Retry limit
• Notifications after failures

Research Insight

Google’s SRE principles recommend letting systems “fail open” — don’t block internal ops due to third-party hiccups.

Conclusion

BPJS API might fail. Internet might lag. But SIMRS shouldn’t collapse just because of that. Let’s build systems that can breathe — not panic — when the network stutters.