Integrasi BPJS: Gambaran Umum untuk Developer

Kalau Anda developer yang baru pertama kali diminta "integrasikan sistem kita dengan BPJS", godaan paling besar adalah langsung buka dokumentasi API dan mulai coding. Saya sendiri, setelah beberapa tahun bekerja di sistem klinik dan rumah sakit, belajar bahwa langkah itu sering berujung rework besar. Integrasi BPJS bukan sekadar tarik-kirim data lewat REST API — di baliknya ada alur klaim dan proses verifikasi yang harus dipahami dulu, karena itu yang menentukan bentuk data, urutan proses, dan penanganan error di sistem kita.

Alur Klaim Secara Garis Besar

Secara umum, perjalanan satu episode layanan pasien BPJS melewati beberapa tahap: penerbitan Surat Eligibilitas Peserta (SEP) di awal layanan, pencatatan layanan medis dan diagnosis selama perawatan, lalu pengajuan klaim setelah episode selesai. Klaim ini kemudian masuk ke proses verifikasi oleh BPJS sebelum akhirnya dibayarkan atau dikembalikan untuk perbaikan (dispute). Sebagai ilustrasi saja, satu episode rawat inap bisa punya puluhan baris data — diagnosis utama, diagnosis sekunder, tindakan, obat — yang semuanya harus konsisten satu sama lain, karena inkonsistensi kecil di tahap pencatatan bisa jadi alasan klaim ditolak di tahap verifikasi.

Titik Integrasi yang Perlu Dipahami

Dari sisi teknis, integrasi biasanya menyentuh beberapa layanan berbeda: layanan untuk cek kepesertaan dan terbitkan SEP, layanan untuk data rujukan atau antrean, dan layanan untuk pengajuan klaim itu sendiri. Masing-masing punya siklus hidup data yang berbeda — SEP dibuat di awal dan jarang berubah, sementara data klaim bisa direvisi berkali-kali sebelum final. Karena itu saya biasanya memisahkan model data di sistem internal antara "data administratif" (SEP, kepesertaan) dan "data klinis-klaim" (diagnosis, tindakan), meskipun keduanya nanti digabung saat pengajuan klaim. Pemisahan ini memudahkan audit dan mempermudah saat salah satu bagian perlu direvisi tanpa mengubah yang lain.

Verifikasi Bukan Sekadar "Kirim Data"

Bagian yang sering diremehkan developer baru adalah tahap verifikasi. Setelah klaim diajukan, statusnya tidak langsung final — bisa pending, butuh perbaikan, atau ditolak sebagian. Sistem kita idealnya punya state machine yang jelas untuk status klaim, bukan sekadar field status bertipe string bebas. Sesuatu seperti:

enum ClaimStatus {
  DRAFT,
  SUBMITTED,
  PENDING_VERIFICATION,
  NEEDS_REVISION,
  VERIFIED,
  REJECTED,
}

Dengan state yang eksplisit, tim rekam medis dan keuangan bisa melacak klaim mana yang butuh tindakan, dan kita sebagai developer punya tempat yang jelas untuk menaruh log audit — siapa mengubah apa, kapan, dan kenapa. Ini penting karena proses verifikasi BPJS bisa berlangsung berhari-hari, jadi sistem kita harus tahan terhadap proses asinkron, bukan mengasumsikan respons langsung datang.

Hal Praktis di Sisi Developer

Beberapa prinsip yang saya pegang saat membangun integrasi semacam ini: pertama, semua panggilan ke layanan eksternal harus idempotent atau minimal aman untuk di-retry, karena jaringan ke layanan pemerintah tidak selalu stabil. Kedua, pisahkan kredensial dan environment antara staging dan produksi secara ketat — jangan sampai data uji coba tercampur dengan data produksi. Ketiga, jangan simpan mentah-mentah payload sensitif di log aplikasi; cukup simpan ID referensi dan status. Terakhir, siapkan mekanisme reconciliation berkala — proses yang membandingkan status klaim di sistem internal dengan status di sisi BPJS — karena pada sistem apa pun yang melibatkan dua pihak, akan selalu ada kondisi di mana kedua sisi sempat tidak sinkron.

Takeaway

Integrasi BPJS pada dasarnya adalah masalah pemodelan proses bisnis dulu, baru masalah teknis API. Kalau Anda memahami alur klaim dan siklus verifikasinya lebih dulu, desain sistem — mulai dari skema data sampai state machine status klaim — akan jauh lebih tahan terhadap perubahan aturan atau format yang biasa terjadi di ekosistem ini.