INA-CBG Dijelaskan Sederhana

Kalau Anda pernah membangun atau memelihara sistem informasi rumah sakit (SIMRS) di Indonesia, cepat atau lambat Anda akan bertemu istilah INA-CBG. Ini bukan sekadar kode administratif yang harus "diisi supaya klaim lolos" — INA-CBG adalah logika bisnis inti yang menentukan bagaimana sebuah episode pelayanan pasien diterjemahkan menjadi satu paket tarif. Sebagai orang yang bekerja di sisi teknis sistem klinik, saya rasa penting bagi developer untuk paham prinsip dasarnya, bukan cuma tahu field mana yang harus dikirim ke aplikasi klaim.

Kenapa ada pengelompokan berbasis diagnosis

Model pembiayaan kesehatan modern umumnya bergerak dari "bayar per tindakan" (fee-for-service) ke "bayar per kasus" (case-based payment). Alasannya sederhana: kalau tarif dihitung dari setiap item yang dipakai, insentifnya jadi condong ke arah "makin banyak tindakan, makin besar tagihan" — yang tidak selalu sejalan dengan kebutuhan medis pasien. INA-CBG (Indonesia Case Base Groups) adalah implementasi Indonesia dari pendekatan Case Mix, di mana setiap episode perawatan dikelompokkan ke dalam satu grup berdasarkan kombinasi diagnosis utama, diagnosis sekunder, prosedur/tindakan, dan beberapa atribut lain seperti usia, jenis kelamin, atau status pulang pasien.

Intinya: dua pasien dengan kondisi klinis yang secara sumber daya "mirip" akan jatuh ke grup tarif yang sama, terlepas dari detail tindakan yang sebenarnya dilakukan. Ini yang membuat sistem ini disebut berbasis diagnosis, bukan berbasis item layanan.

Bagaimana prinsip pengelompokan bekerja

Secara konsep, ada komponen yang biasa disebut "grouper" — mesin logika yang menerima input berupa kode diagnosis (memakai standar ICD-10) dan kode prosedur (ICD-9-CM), lalu mengeluarkan satu kode grup CBG. Sebagai ilustrasi saja, bukan angka nyata: sebuah kasus dengan diagnosis utama tertentu plus komplikasi bisa jatuh ke grup dengan tingkat keparahan (severity level) lebih tinggi dibanding kasus yang sama tanpa komplikasi, dan tarifnya pun berbeda.

Yang perlu dipahami developer adalah bahwa hasil grouping sangat bergantung pada kualitas input diagnosis. Kalau diagnosis utama yang dikirim tidak mencerminkan kondisi yang paling banyak menyerap sumber daya perawatan, atau diagnosis sekunder yang relevan tidak ikut tercatat, grouper bisa menghasilkan grup yang tidak sesuai dengan kompleksitas kasus sebenarnya. Ini bukan soal "salah ketik kode", tapi soal bagaimana proses pencatatan diagnosis di rekam medis elektronik dirancang agar informasi yang relevan benar-benar sampai ke sistem koding.

Kenapa ini relevan buat developer, bukan cuma tim koding

Di banyak fasilitas kesehatan, proses dari "dokter menulis diagnosis" sampai "kode diagnosis final dikirim ke aplikasi klaim" itu melewati beberapa sistem: SIMRS, modul rekam medis, kadang alat bantu koding, baru masuk ke aplikasi eligibilitas dan klaim. Setiap titik integrasi ini adalah tempat informasi bisa hilang atau berubah bentuk — misalnya diagnosis sekunder yang tercatat di catatan dokter tapi tidak ikut terbawa ke field terstruktur yang dibaca sistem koding.

Di sinilah menurut saya peran developer jadi penting: bukan menentukan kode yang benar (itu tetap ranah tenaga koding medis dan dokter), tapi memastikan arsitektur data mendukung alur informasi yang lengkap dan konsisten. Saya sendiri terlibat membangun alat bantu koding berbasis AI seperti di medcoder.pujamalca.my.id, dan pengalaman itu membuat saya makin sadar bahwa masalah paling umum bukan di algoritma groupingnya, tapi di kualitas dan kelengkapan data yang masuk ke proses itu.

Yang perlu diingat

INA-CBG pada dasarnya adalah cara menerjemahkan kompleksitas klinis satu episode perawatan menjadi satu angka tarif, lewat pengelompokan berbasis diagnosis dan prosedur. Sebagai developer, tugas kita bukan menghafal tabel tarif atau aturan koding, tapi memahami bahwa kualitas data diagnosis yang mengalir lewat sistem kita punya dampak langsung ke hasil akhir proses ini. Desain integrasi yang menjaga kelengkapan dan konsistensi data diagnosis, dari rekam medis sampai ke aplikasi klaim, adalah kontribusi teknis yang nyata terhadap keakuratan proses INA-CBG secara keseluruhan.