VEDIKA BPJS: Cara RS Menyiapkan SIMRS untuk Verifikasi Digital Klaim

Sejak awal 2025, banyak Direktur RS merasakan tekanan arus kas yang tidak wajar: klaim BPJS Kesehatan yang sebelumnya diproses dalam 15 hari kini tertahan berminggu-minggu tanpa notifikasi yang jelas. Perhimpunan Rumah Sakit Seluruh Indonesia (PERSI) mencatat kenaikan klaim mandek rata-rata sekitar 20 persen di seluruh anggotanya, dengan nominal mencapai ratusan miliar rupiah pada Oktober 2024.

Di balik kenaikan ini ada satu faktor yang kerap tidak dipahami tim internal RS: BPJS Kesehatan memperketat verifikasi klaim sebagai tindak lanjut rekomendasi Komisi Pemberantasan Korupsi (KPK) untuk mencegah kecurangan (fraud). Alat utama yang digunakan adalah VEDIKA — sistem Verifikasi Digital Klaim yang sudah beroperasi sejak 2018, tetapi kini bekerja dengan standar yang jauh lebih ketat dan otomatis.

Hal yang lebih kritis untuk Direktur RS bukan "apakah kami tahu VEDIKA?" tetapi "apakah SIMRS kami sudah benar-benar siap untuk melewati VEDIKA secara konsisten?"

Apa Itu VEDIKA dan Bagaimana Cara Kerjanya

VEDIKA adalah proses verifikasi klaim yang diajukan oleh FKRTL (Fasilitas Kesehatan Rujukan Tingkat Lanjutan) menggunakan aplikasi digital milik BPJS Kesehatan — menggantikan verifikator manusia yang sebelumnya memeriksa berkas fisik di kantor cabang. Sistem ini menggunakan dua aplikasi inti: VClaim untuk penerbitan SEP (Surat Eligibilitas Peserta) dan pengajuan klaim, serta Vidi (Verifikasi Digital) untuk pemeriksaan klaim secara otomatis.

VEDIKA diterapkan secara penuh untuk seluruh FKRTL sejak Mei 2018. BPJS Kesehatan menyebutkan bahwa lebih dari 99% FKRTL mitra telah mengimplementasikan VEDIKA, artinya seluruh klaim dari rumah sakit kini melewati sistem digital ini tanpa pengecualian.

Alur kerja VEDIKA berjalan linier:

1. RS menerbitkan SEP pasien melalui VClaim (atau melalui bridging SIMRS ke VClaim API)
2. Setelah pelayanan selesai, klaim diinput di SIMRS dan dikirim ke server BPJS
3. VEDIKA memverifikasi klaim secara digital: kelengkapan berkas, kesesuaian koding, sinkronisasi data SEP dengan data episode
4. Klaim yang lolos masuk antrean pembayaran; klaim bermasalah masuk status "pending" tanpa pembayaran

Masalah utama: ketika VEDIKA menahan klaim, tidak selalu ada notifikasi eksplisit ke RS. Tim klaim sering baru menyadari masalah saat mengecek status secara manual — dan saat itu, nilai klaim yang tertahan sudah menumpuk selama berminggu-minggu.

Mengapa Klaim RS Tertahan di VEDIKA: 4 Penyebab Struktural

Penelitian terhadap pola klaim pending di berbagai RS menunjukkan bahwa penolakan tidak terjadi secara acak. Ada empat penyebab struktural yang berulang dan dapat dicegah dengan kesiapan SIMRS yang tepat:

1. Ketidaklengkapan Berkas Administrasi

Berkas tidak lengkap secara konsisten menjadi penyebab pending terbanyak di berbagai RS. Ketidaklengkapan yang paling sering ditemukan: SEP tidak terlampir dalam berkas digital, resume medis tidak ikut diunggah, laporan operasi untuk tindakan bedah tidak ada, surat rujukan tidak tervalidasi, atau surat keterangan rawat inap hilang.

VEDIKA memverifikasi kelengkapan berkas secara otomatis berdasarkan jenis pelayanan dan tindakan. SIMRS yang tidak memiliki checklist kelengkapan berkas otomatis sebelum pengiriman akan selalu menghadapi risiko ini, tanpa peduli seberapa kompeten tim koder-nya.

2. Kesalahan Koding INA-CBG

Kesalahan koding menjadi penyebab signifikan kedua. Masalah yang paling umum: diagnosis utama tidak sesuai dengan severity group yang diklaim, kode prosedur ICD-9-CM tidak dilengkapi untuk tindakan yang mensyaratkannya, atau ada mismatch antara diagnosis yang tercatat di rekam medis dengan koding yang diajukan ke BPJS.

VEDIKA secara otomatis mencocokkan koding dengan database INA-CBG dan tarif yang diklaim. Koding yang tidak konsisten dengan severity group — misalnya mengklaim severity III tetapi diagnosis sekunder tidak mendukung — akan langsung ditahan. Perlu diingat: koding INA-CBG menggunakan ICD-10 WHO 2010 untuk diagnosis dan ICD-9-CM untuk prosedur; bukan ICD-10-CM versi Amerika.

3. SEP Tidak Sinkron dengan Data Episode

SEP diterbitkan saat pasien masuk. Namun jika data episode di SIMRS tidak sinkron dengan data SEP di server V-Claim BPJS — misalnya karena bridging tidak berjalan sempurna, terjadi input manual yang berbeda, atau ada delay sinkronisasi — VEDIKA akan mendeteksi inkonsistensi dan menahan klaim.

Ini adalah masalah teknis murni yang berkaitan langsung dengan kualitas integrasi antara SIMRS dan VClaim API. RS yang masih mengandalkan sebagian proses input manual di luar SIMRS memiliki risiko mismatch yang lebih tinggi.

4. Format Berkas Tidak Sesuai Spesifikasi Digital BPJS

BPJS memiliki spesifikasi format untuk pengajuan klaim digital: ukuran file, format dokumen, penamaan field, dan struktur data. SIMRS yang menggunakan format lama atau yang tidak diperbarui sesuai spesifikasi terbaru VEDIKA akan menghasilkan klaim yang otomatis ditolak — bahkan sebelum konten klaim diperiksa secara substantif.

Masalah format ini sering tidak terdeteksi sampai klaim sudah dikirim, karena SIMRS yang lama tidak memiliki validasi format internal sebelum pengiriman.

3 Kesiapan SIMRS yang Menentukan Lolos-Tidaknya Klaim di VEDIKA

Permenkes No. 82 Tahun 2013 tentang SIMRS mewajibkan seluruh RS mengimplementasikan modul integrasi eksternal, termasuk bridging ke sistem BPJS Kesehatan (VClaim, eClaim, Aplicares). Namun "sudah ada bridging" berbeda dari "bridging berfungsi optimal untuk standar VEDIKA saat ini." Ada tiga tingkat kesiapan SIMRS yang perlu diperiksa Direktur RS:

Bridging VClaim berarti SIMRS terhubung langsung ke API resmi VClaim BPJS Kesehatan — petugas tidak perlu membuka dua sistem terpisah untuk menerbitkan SEP atau memverifikasi kepesertaan. Ketika pasien mendaftar, SIMRS secara otomatis meminta data kepesertaan dari server BPJS dan menerbitkan SEP dalam hitungan detik.

Hal yang perlu dicek Direktur RS:

• Apakah bridging menggunakan token API yang masih aktif dan terdaftar di BPJS Kesehatan?
• Apakah SEP diterbitkan otomatis dari SIMRS, atau masih ada tahap input manual yang bisa menyebabkan mismatch?
• Apakah ada mekanisme retry otomatis ketika server VClaim mengalami timeout? Ini penting terutama di awal bulan ketika server BPJS melakukan sinkronisasi masif data kepesertaan jutaan peserta.

RS yang masih mengandalkan input SEP manual — terpisah dari alur kerja SIMRS — memiliki risiko inkonsistensi data yang tinggi di VEDIKA, bahkan jika bridging secara teknis sudah terpasang.

Ini adalah langkah yang paling sering diabaikan, padahal paling mudah diterapkan: SIMRS harus memiliki checklist validasi internal yang berjalan otomatis sebelum klaim dikirim ke BPJS. Tujuannya sederhana — menangkap error di sisi RS sebelum VEDIKA menangkapnya.

Checklist minimal yang efektif mencakup:

• SEP terlampir dan nomor SEP konsisten dengan data episode pasien
• Resume medis atau surat keterangan medis ada dan terlampir sesuai jenis pelayanan
• Koding diagnosis primer dan sekunder lengkap — kode ICD-10 WHO 2010, bukan ICD-10-CM Amerika
• Kode prosedur ICD-9-CM dilengkapi untuk semua tindakan yang mensyaratkan kode prosedur
• Format file sesuai spesifikasi terbaru BPJS: ukuran, format, nama field yang tepat

Tanpa validasi internal ini, RS efektif membiarkan VEDIKA menjadi detektor error pertama — dan itu sudah terlambat, karena penolakan sudah terjadi di sisi BPJS.

VEDIKA tidak selalu mengirimkan notifikasi eksplisit saat klaim ditahan. RS yang tidak memiliki dashboard monitoring akan mengetahui penolakan hanya saat melakukan pengecekan manual ke portal BPJS — saat itu, nilai pending sudah terakumulasi selama berminggu-minggu.

Dashboard monitoring yang efektif harus menampilkan setidaknya:

• Status setiap batch klaim yang dikirim: terkirim / diproses / pending / ditolak
• Breakdown alasan penolakan per klaim untuk tindakan korektif yang tepat sasaran
• Aging analysis: klaim mana yang sudah berapa hari belum direspons
• Alert otomatis ketika persentase pending melebihi ambang batas yang ditetapkan manajemen

Catatan untuk ke depan: SatuSehat secara bertahap akan menjadi jembatan data antara RS dan BPJS Kesehatan untuk validasi klaim. RS yang SIMRS-nya sudah terintegrasi dengan SatuSehat sesuai PMK 24/2022 akan memiliki visibilitas data lebih baik dan risiko inkonsistensi data yang lebih kecil saat proses validasi klaim.

Dampak Nyata: Dari Pending Klaim ke Tekanan Operasional

Klaim yang tertahan bukan hanya angka di laporan keuangan. Setiap klaim pending berarti RS sudah mengeluarkan biaya pelayanan — obat, jasa tenaga kesehatan, penunjang, kamar — tetapi belum menerima pembayaran. Kompas.id melaporkan klaim tertunda BPJS Kesehatan secara nasional pernah mencapai Rp 5 triliun.

Dampak nyata ke operasional RS bersifat berantai:

• Arus kas terganggu: RS tetap harus memenuhi kewajiban rutin — gaji, farmasi, operasional — tanpa penerimaan klaim yang semestinya sudah cair
• Jaspel terlambat dibayarkan: Dokter spesialis dan tenaga kesehatan menerima insentif lebih lambat, yang berpotensi memengaruhi retensi dan moral
• Kapasitas layanan tertekan: Beberapa RS mulai membatasi stok obat atau alat penunjang karena keterbatasan kas, yang pada akhirnya berdampak pada pasien

Setelah BPJS memperketat verifikasi, RS Kelas A tercatat mengalami penurunan signifikan persentase klaim pending setelah memperbaiki sistem internal mereka. Ini menunjukkan bahwa penolakan klaim bukan harga mati — ini masalah yang bisa diselesaikan dengan kesiapan sistem yang tepat.

Dalam konteks ini, memastikan SIMRS siap untuk VEDIKA bukan pengeluaran IT biasa. Ini adalah manajemen risiko finansial yang langsung memengaruhi keberlangsungan operasional rumah sakit.

Dasar Hukum

• Permenkes No. 82 Tahun 2013 tentang Sistem Informasi Manajemen Rumah Sakit — mewajibkan seluruh RS mengimplementasikan SIMRS dengan modul integrasi eksternal termasuk bridging ke sistem BPJS Kesehatan (VClaim, eClaim, Aplicares)
• Permenkes No. 24 Tahun 2022 tentang Rekam Medis — mewajibkan RS menggunakan RME yang terintegrasi dengan platform nasional SatuSehat, yang secara bertahap digunakan untuk validasi dan sinkronisasi data klaim BPJS
• Permenkes No. 26 Tahun 2021 tentang Pedoman Indonesian Case Base Groups (INA-CBG) — menetapkan standar koding diagnosis dan prosedur yang harus dipenuhi dalam pengajuan klaim; koding yang tidak sesuai standar ini akan ditahan di VEDIKA

FAQ

Apa itu VEDIKA BPJS Kesehatan?

VEDIKA (Verifikasi Digital Klaim) adalah sistem verifikasi klaim BPJS Kesehatan yang dilakukan secara digital menggunakan aplikasi VClaim dan Vidi. Sistem ini menggantikan verifikasi manual berkas fisik dan sudah diterapkan di seluruh FKRTL sejak Mei 2018. VEDIKA bekerja otomatis — klaim yang tidak memenuhi standar ditahan tanpa perlu intervensi verifikator manusia di kantor cabang BPJS.

Apakah SIMRS yang sudah lama masih bisa digunakan untuk VEDIKA?

Bisa, selama bridging VClaim API masih aktif dan terdaftar di BPJS, dan SIMRS diperbarui sesuai spesifikasi terbaru. Masalah yang paling sering muncul pada SIMRS lama: token API kadaluarsa, format berkas klaim yang sudah tidak sesuai spesifikasi terbaru, atau tidak adanya modul monitoring status klaim per batch. Audit teknis berkala terhadap kondisi bridging dan kelengkapan modul klaim sangat disarankan.

Berapa lama klaim yang tertahan di VEDIKA bisa diselesaikan?

Klaim pending yang disebabkan oleh ketidaklengkapan berkas atau kesalahan koding umumnya bisa diselesaikan dalam 3–7 hari kerja setelah berkas direvisi dan dikembalikan ke BPJS. Namun semakin lama klaim dibiarkan pending tanpa tindakan, semakin besar risiko melewati batas waktu pengajuan ulang yang ditetapkan BPJS, yang dapat berujung pada penolakan permanen.

Apakah SatuSehat memengaruhi proses klaim BPJS lewat VEDIKA?

Ya, secara bertahap. SatuSehat akan menjadi jembatan data antara RS dan BPJS Kesehatan — data yang sudah dikirim RS ke SatuSehat (RME, diagnosis, prosedur) akan digunakan untuk validasi klaim di sistem BPJS, mengurangi duplikasi input data. RS yang belum mengintegrasikan SIMRS dengan SatuSehat sesuai PMK 24/2022 akan menghadapi risiko ketidaksesuaian data yang lebih tinggi ke depannya.

Apa bedanya VEDIKA dengan proses verifikasi BPJS sebelumnya?

Sebelum VEDIKA, verifikasi klaim dilakukan oleh staf verifikator manusia di kantor cabang BPJS yang memeriksa berkas fisik secara manual. VEDIKA mengotomatiskan proses ini — verifikasi dilakukan secara digital oleh sistem, lebih konsisten, lebih cepat, tetapi juga lebih ketat karena tidak ada ruang untuk pertimbangan subjektif. Standar format dan kelengkapan diterapkan seragam tanpa pengecualian.

Sumber

• PERSI, dilaporkan Tempo.co: "Klaim Mandek di BPJS Kesehatan Melonjak 20 Persen, Rumah Sakit: Kami Hampir Tenggelam" (2024)
• Kompas.id: "Klaim Tertunda BPJS Kesehatan Capai Rp 5 Triliun, Layanan ke Masyarakat Bisa Terdampak" (2024)
• BPJS Kesehatan RI, keterangan resmi via @BPJSKesehatanRI (2018): definisi dan implementasi VEDIKA untuk seluruh FKRTL
• Permenkes No. 82 Tahun 2013 tentang Sistem Informasi Manajemen Rumah Sakit — Kemenkes RI
• Permenkes No. 24 Tahun 2022 tentang Rekam Medis — Kemenkes RI
• Permenkes No. 26 Tahun 2021 tentang Pedoman INA-CBG — Kemenkes RI