jalur klaim jkn pcare vclaim eklaim

🩺💻🏥💰

Seri Pertukaran Informasi Kesehatan: Artikel 3 dari 16

Menelusuri Jalur Klaim JKN: Peran P-Care, VClaim, dan E-Klaim INA-CBG

Ikuti satu data pasien dari loket puskesmas sampai rekening rumah sakit, dan lihat di mana klaim bisa tersangkut.

#JKN#PCare#VClaim#EKlaimINACBG#MIK

9 menit

Estimasi baca

Menengah

Level

2026

Tahun

Bayangkan kamu berobat dengan kartu JKN: demam tiga hari, periksa ke puskesmas, lalu dirujuk ke rumah sakit. Dari kursi pasien, kamu cuma merasa duduk, diperiksa, lalu pulang. Di belakang layar, data kamu menempuh perjalanan lewat tiga aplikasi sekaligus: P-Care VClaim E-Klaim INA-CBG. Kalau satu mata rantai macet, klaim rumah sakit ikut tertahan dan arus kas fasilitas kesehatan ikut seret.

Kalau kamu mahasiswa D4 Manajemen Informasi Kesehatan, jalur ini bukan teori kosong. Kamu akan bertemu dengannya di tempat PKL, di meja koder, bahkan di skripsi. Di artikel ini kamu akan menelusuri peran tiap aplikasi, melihat urutan data bergerak, dan menyusun checklist validasi sendiri. Artikel ini bagian dari seri Pertukaran Informasi Kesehatan.

Peta Besar P-Care VClaim E-Klaim INA-CBG dalam Ekosistem JKN

Mari mulai dari pertanyaan sederhana: kenapa JKN butuh tiga aplikasi, bukan satu aplikasi raksasa? Jawabannya ada pada siapa yang bekerja dan apa yang dihitung. Puskesmas, rumah sakit, BPJS Kesehatan, dan Kementerian Kesehatan punya peran, kewenangan, dan sistem sendiri, sehingga data harus berpindah dari satu pihak ke pihak lain tanpa kehilangan makna.

JKN diselenggarakan BPJS Kesehatan berdasarkan Peraturan Presiden Nomor 82 Tahun 2018 tentang Jaminan Kesehatan. Pelayanannya berjenjang: peserta mulai dari Fasilitas Kesehatan Tingkat Pertama (FKTP) seperti puskesmas dan klinik pratama, lalu masuk ke Fasilitas Kesehatan Rujukan Tingkat Lanjutan (FKRTL) seperti rumah sakit lewat rujukan.

Cara bayarnya juga berbeda. FKTP menerima kapitasi, yaitu pembayaran per peserta terdaftar. Rumah sakit dibayar dengan tarif paket INA-CBG, yaitu satu kasus satu paket berdasarkan pengelompokan diagnosis dan prosedur. Pedoman pengelompokannya diatur dalam Permenkes Nomor 26 Tahun 2021, sedangkan standar tarifnya dalam Permenkes Nomor 3 Tahun 2023. Dua logika bayar berarti dua jenis data, dan itu sebabnya aplikasinya berbeda.

Pakai analogi naik kereta antarkota. P-Care adalah loket stasiun asal yang mencatat siapa berangkat dan kenapa. VClaim adalah gerbang pemeriksa tiket, yaitu memastikan penumpang sah dan tiketnya (SEP) terbit. E-Klaim INA-CBG adalah kasir di stasiun tujuan yang menghitung berapa paket tarif perjalanan itu.

🧮 Rumus Alur Klaim (versi sederhana)

Kunjungan FKTP (P-Care) → Rujukan dan SEP (VClaim) → Koding dan grouping (E-Klaim INA-CBG) → Verifikasi dan pembayaran BPJS Kesehatan

Definisi kerja: klaim JKN adalah tagihan fasilitas kesehatan ke BPJS Kesehatan atas pelayanan peserta, yang harus didukung data pelayanan yang sah, konsisten, dan lengkap.

💡 Tips: Tanya soal asal nomor SEP

Saat PKL di rumah sakit, tanyakan ke petugas pendaftaran: "Nomor SEP ini terbit dari mana dan siapa yang memvalidasinya?" Satu pertanyaan itu langsung membuka peta bridging SIMRS kamu.

Membedah P-Care, VClaim, dan E-Klaim INA-CBG Satu per Satu

P-Care: buku harian kunjungan di FKTP

P-Care adalah aplikasi BPJS Kesehatan untuk FKTP. Petugas mencatat pendaftaran kunjungan, diagnosis (ICD-10), tindakan, obat, dan rujukan di sini. Di puskesmas, data biasanya berasal dari SIMPUS lalu dikirim ke P-Care lewat bridging. Kamu sudah bertemu konsep ini di artikel SIMRS, SIMPUS, dan RME sebelumnya.

VClaim: gerbang keabsahan dan SEP

VClaim dipakai untuk mengecek status kepesertaan, memvalidasi rujukan, menerbitkan Surat Eligibilitas Peserta (SEP), dan memantau klaim. Rumah sakit umumnya mengakses VClaim lewat web service yang tersambung ke SIMRS, sehingga petugas tidak perlu mengetik ulang data.

E-Klaim INA-CBG: mesin grouping tarif paket

E-Klaim INA-CBG dikembangkan dan didistribusikan Pusat Data dan Informasi (Pusdatin) Kementerian Kesehatan. Koder memasukkan data pasien, diagnosis ICD-10, dan prosedur ICD-9-CM. Grouper kemudian menghasilkan kode INA-CBG beserta tarifnya, dan rumah sakit mengekspor hasilnya sebagai berkas klaim untuk diverifikasi BPJS Kesehatan.

Perhatikan pola pembagian tugasnya. P-Care dan VClaim sama-sama milik BPJS Kesehatan, tetapi P-Care berfokus pada pencatatan pelayanan di FKTP, sedangkan VClaim berfokus pada keabsahan dan administrasi peserta lintas fasilitas. E-Klaim INA-CBG berasal dari Kementerian Kesehatan karena tugasnya adalah standar pengelompokan kasus, bukan administrasi kepesertaan. Tabel berikut merangkum perbedaannya supaya kamu bisa membuat catatan cepat.

Aspek	P-Care	VClaim	E-Klaim INA-CBG
Pengelola	BPJS Kesehatan	BPJS Kesehatan	Kemenkes (Pusdatin)
Pengguna utama	FKTP	FKTP dan rumah sakit	Rumah sakit (koder, casemix)
Fungsi inti	Catat kunjungan, diagnosis, rujukan	Cek peserta, rujukan, terbitkan SEP, pantau klaim	Koding, grouping, hitung tarif paket
Pola pembayaran terkait	Kapitasi	Penghubung keabsahan pelayanan	Paket INA-CBG
Output	Data kunjungan dan rujukan	Nomor SEP	Kode dan tarif INA-CBG, berkas klaim

🔥 Fakta Menarik: Dua logika bayar dalam satu sistem

Puskesmas dibayar kapitasi per peserta terdaftar, walau bulan ini tidak ada yang sakit. Rumah sakit dibayar per paket kasus. Karena itu data P-Care menekankan kunjungan dan rujukan, sedangkan data E-Klaim menekankan ketepatan koding (Perpres No. 82/2018; Permenkes No. 3/2023).

Menelusuri Jalur Klaim JKN dari FKTP sampai Pembayaran

Sekarang kita gabungkan ketiganya. Ikuti satu pasien hipotetis dari puskesmas sampai klaim rumah sakit dibayar:

1

Catat kunjungan di FKTP

Petugas memverifikasi kepesertaan, lalu mencatat kunjungan di P-Care lewat SIMPUS atau input langsung.

2

Tetapkan diagnosis dan terbitkan rujukan

Dokter menegakkan diagnosis (ICD-10). Jika kasus perlu layanan lanjutan, rujukan tercatat di sistem BPJS Kesehatan.

3

Validasi di VClaim saat pendaftaran rumah sakit

Petugas pendaftaran memeriksa kepesertaan dan rujukan, lalu menerbitkan SEP. Tanpa SEP yang sah, klaim sulit berlanjut.

4

Layani pasien dan lengkapi rekam medis

Dokter mengisi resume medis, hasil penunjang, dan tindakan. Dokumentasi inilah bahan baku koder.

5

Koding dan grouping di E-Klaim INA-CBG

Koder menetapkan ICD-10 dan ICD-9-CM, menjalankan grouper, memeriksa kode INA-CBG hasilnya, lalu memfinalisasi klaim.

6

Kirim, verifikasi, bayar

BPJS Kesehatan memverifikasi kelengkapan dan kesesuaian berkas. Klaim yang sesuai dibayar, sedangkan klaim bermasalah berstatus pending dan kembali ke rumah sakit untuk diperbaiki.

Contoh mini: seorang pasien dengan batuk dan sesak datang ke puskesmas, dicatat di P-Care, lalu dirujuk ke rumah sakit karena dicurigai pneumonia. Di rumah sakit, petugas memvalidasi rujukan lewat VClaim dan SEP terbit. Dokter merawat pasien tiga hari. Koder membaca resume medis, menetapkan kode diagnosis (misalnya J18.9 untuk pneumonia yang tidak spesifik) beserta kode tindakan bila ada, lalu E-Klaim INA-CBG menghasilkan kelompok dan tarif paketnya. Kalau resume medis menyebut diagnosis berbeda dari yang diinput, verifikator akan melihat ketidaksesuaian itu.

⚡ Insight Penting: Data mengalir ke depan, kesalahan juga

Diagnosis yang salah di FKTP bisa terbawa sampai rujukan. Nomor SEP yang keliru terbawa sampai berkas klaim. Satu kesalahan kecil di hulu mudah menjadi klaim pending di hilir, jadi validasi di titik masuk jauh lebih murah daripada memperbaiki di akhir.

🔍 Analisis: Di Mana Data Paling Rawan Bocor?

SIMPUS ke P-Care
Risiko: diagnosis atau data peserta tidak terkirim dan tidak tercatat di sisi BPJS.

SIMRS ke VClaim
Risiko: SEP tidak sinkron dengan data kunjungan atau rujukan.

SIMRS ke E-Klaim
Risiko: kode tidak sesuai resume medis, atau berkas pendukung tidak lengkap.

Penelitian administrasi klaim di rumah sakit berulang kali menyoroti ketidaksesuaian koding dan kelengkapan berkas sebagai sumber klaim pending. Artinya, peranmu sebagai calon perekam medis dan koder menentukan.

Kode Praktis: Validasi Data Sebelum Masuk E-Klaim INA-CBG

Kamu tidak perlu menunggu jadi koder untuk melatih ketelitian. Skrip Python berikut hanya ilustrasi belajar, bukan API resmi BPJS atau Kemenkes. Fungsinya memeriksa konsistensi dasar satu berkas klaim sebelum dikirim:

🔴🟡🟢validasi_klaim.py

# Ilustrasi pembelajaran: pengecekan dasar sebelum klaim dikirim
import re
from datetime import date

def cek_klaim(k):
    masalah = []
    if not k.get("no_sep"):
        masalah.append("Nomor SEP kosong")
    if not re.fullmatch(r"[A-Z]\d{2}(\.\d{1,2})?", k.get("dx_utama", "")):
        masalah.append("Format ICD-10 diagnosis utama tidak valid")
    if k["tgl_pulang"] < k["tgl_masuk"]:
        masalah.append("Tanggal pulang lebih awal dari tanggal masuk")
    if not k.get("resume_medis_lengkap"):
        masalah.append("Resume medis belum lengkap")
    return masalah

contoh = {
    "no_sep": "",
    "dx_utama": "J18.9",
    "tgl_masuk": date(2026, 11, 2),
    "tgl_pulang": date(2026, 11, 5),
    "resume_medis_lengkap": False,
}
for m in cek_klaim(contoh):
    print("Perbaiki:", m)

Jalankan skrip itu, lalu ubah contoh datanya sampai semua pesan masalah hilang. Latihan ini mengajarkan satu kebiasaan penting: mengecek data sebelum mengirim, bukan sesudah ditolak. Di dunia kerja, kebiasaan ini disebut validasi data: sistem atau orang memeriksa aturan sederhana sebelum data berpindah ke tahap berikutnya. Pola yang sama berlaku di setiap bridging, mulai dari SIMPUS ke P-Care sampai SIMRS ke VClaim.

Kamu juga bisa memakai pola ini untuk tugas kuliah. Pilih satu alur, gambar diagram aliran datanya, tandai titik tempat data berpindah sistem, lalu tulis satu aturan validasi untuk setiap titik. Dosen akan melihat bahwa kamu paham bukan hanya nama aplikasinya, tetapi juga logika pertukaran informasinya, dan itu inti mata kuliah ini.

Tiga langkah menerapkannya di tempat PKL: (1) minta contoh berkas klaim yang sudah dianonimkan, (2) tandai tiga kesalahan yang paling sering muncul, (3) ubah tiga kesalahan itu menjadi aturan cek seperti pada skrip di atas.

⚠️ Perhatian: Status iDRG per Oktober 2026

Kementerian Kesehatan sedang menyiapkan transisi dari INA-CBG ke iDRG (Indonesia Diagnosis Related Group). Berdasarkan sumber yang kami telusuri, tarif klaim JKN yang berlaku masih INA-CBG menurut Permenkes No. 3 Tahun 2023 dan iDRG masih tahap uji coba. Kebijakan ini bisa berubah, jadi cek JDIH Kemenkes dan informasi resmi BPJS Kesehatan sebelum kamu menulis tugas akhir.

🎯 Kesimpulan: Satu Jalur, Tiga Penjaga

Jalur klaim JKN berjalan lewat P-Care VClaim E-Klaim INA-CBG. P-Care mencatat kunjungan di FKTP, VClaim memastikan keabsahan peserta dan menerbitkan SEP, dan E-Klaim INA-CBG mengubah diagnosis serta prosedur menjadi tarif paket untuk rumah sakit. BPJS Kesehatan lalu memverifikasi hasilnya.

Ingat tiga hal: kualitas data di hulu menentukan nasib klaim di hilir, koding harus sesuai dokumentasi klinis, dan regulasi tarif terus bergerak. Kamu yang menguasai alur ini akan jadi lulusan MIK yang dicari.

Di tempat PKL-mu, mata rantai mana yang paling sering macet? Tulis di kolom komentar, lalu bagikan artikel ini ke teman satu angkatan.

Tulis komentar Bagikan via WhatsApp

📚 Referensi

1. Peraturan Presiden Republik Indonesia Nomor 82 Tahun 2018 tentang Jaminan Kesehatan.
2. Peraturan Menteri Kesehatan Nomor 26 Tahun 2021 tentang Pedoman Indonesian Case Base Groups (INA-CBG) dalam Pelaksanaan Jaminan Kesehatan.
3. Peraturan Menteri Kesehatan Nomor 3 Tahun 2023 tentang Standar Tarif Pelayanan Kesehatan dalam Penyelenggaraan Program Jaminan Kesehatan.
4. Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.

Teks lengkap dapat dicek di JDIH Kemenkes. Nama aplikasi dan alur operasional dapat berbeda antarfasilitas, jadi selalu rujuk petunjuk teknis terbaru.

Tag

#PertukaranData#PertukaranInformasi#Kesehatan#PCare#VClaim#EKlaim#INACBG

Label

Jalur Klaim JKNP-Care VClaim E-Klaim INA-CBGPertukaran Informasi Kesehatan

📖

Pertukaran Informasi Kesehatan

Lihat Daftar Isi Kuliah Pertukaran Informasi Kesehatan (seri 16 artikel)

Artikel Sebelumnya

SIMRS, SIMPUS, dan RME: Siapa yang Memproduksi Data dan Siapa yang Mengirimnya?

Artikel Selanjutnya

Rujukan Digital dan Pusat Data Nasional: SISRUTE dan SATUSEHAT dalam Satu Peta Arsitektur

simrs simpus rme

🏥 🏡 📋

Pertukaran Informasi Kesehatan · Artikel 2/16

SIMRS, SIMPUS, dan RME: Siapa yang Memproduksi Data dan Siapa yang Mengirimnya?

Tiga istilah yang sering dipakai bergantian, padahal perannya beda. Kita bedah satu per satu.

#SIMRS#SIMPUS#RME#SATUSEHAT

⏱️

±9 menit

estimasi baca

🎓

D4 MIK

level

📅

2026

tahun

Bayangkan kamu magang di rumah sakit dan atasanmu bertanya, “Data pasien ini dibuat di SIMRS atau di RME? Siapa yang mengirim ke Kemenkes?” Kalau kamu berhenti sebentar sebelum menjawab, kamu tidak sendirian. Banyak mahasiswa dan praktisi menyamakan SIMRS SIMPUS RME sebagai satu benda yang sama.

Padahal, salah menjawab pertanyaan itu berarti salah menunjuk sumber masalah saat data gagal terkirim. Artikel ini membantumu menjawab dengan yakin: siapa yang memproduksi data, dan siapa yang mengirimnya. Kamu sedang membaca artikel 2 dari 16 seri Pertukaran Informasi Kesehatan.

SIMRS SIMPUS RME: Tiga Istilah, Tiga Peran Berbeda

Pakai analogi restoran. RME adalah isi pesanan dan resep: apa yang dipesan, bagaimana dimasak. SIMRS dan SIMPUS adalah dapur, kasir, dan sistem pemesanannya. Pesanan tanpa dapur tidak bisa diproses, dapur tanpa pesanan tidak menghasilkan apa-apa. Keduanya saling membutuhkan, tapi bukan benda yang sama.

📐 Rumus Konsep

RME = isi catatan pasien
SIMRS / SIMPUS = sistem yang menyimpan dan mengolahnya

Rumah sakit memakai SIMRS, puskesmas memakai SIMPUS. Keduanya menjadi tempat RME hidup.

Istilah	Fungsi	Siapa yang mengisi	Posisi
RME	Isi catatan: identitas, anamnesis, diagnosis, tindakan, resep	Dokter, perawat, bidan, apoteker, petugas lab	Berupa data, bukan aplikasi
SIMRS	Aplikasi pengelola layanan rumah sakit (daftar, rawat inap, farmasi, kasir)	Semua unit RS lewat modul masing-masing	Wadah RME di rumah sakit
SIMPUS	Aplikasi pengelola layanan puskesmas (KIA, poli, laporan program)	Petugas pendaftaran, poli, apotek, program	Wadah RME di puskesmas

Dasar hukumnya jelas. Permenkes Nomor 24 Tahun 2022 tentang Rekam Medis mewajibkan fasilitas pelayanan kesehatan menyelenggarakan rekam medis elektronik. Permenkes Nomor 82 Tahun 2013 mengatur SIMRS, sedangkan Permenkes Nomor 31 Tahun 2019 mengatur Sistem Informasi Puskesmas (istilah resmi untuk yang biasa kita sebut SIMPUS).

💡 Tips: Hafalkan dengan Pertanyaan “Apa vs Di Mana”

Saat membaca dokumen, tanyakan dua hal. “Apa isinya?” jawabannya RME. “Di mana dikelola?” jawabannya SIMRS atau SIMPUS. Kebiasaan kecil ini mencegah kamu salah istilah di laporan magang atau skripsi.

Siapa yang Memproduksi Data di SIMRS SIMPUS RME?

Jawabannya: manusia di fasilitas kesehatan, bukan sistemnya. Sistem hanya menampung. Dalam satu kunjungan rawat jalan, data lahir dari banyak tangan:

🔍 Analisis: Peta Produsen Data dalam Satu Kunjungan

🧾 Petugas pendaftaran → identitas, jenis penjamin
🩺 Dokter dan perawat → keluhan, tanda vital, diagnosis, tindakan
🧪 Analis laboratorium → hasil pemeriksaan
💊 Apoteker → resep dan pengeluaran obat
💳 Kasir → tagihan dan pembayaran
🗂️ Perekam medis dan informasi kesehatan (kamu!) → verifikasi kelengkapan, pengodean diagnosis dan tindakan

Perhatikan peran terakhir. Sebagai lulusan D4 MIK, kamu berada di titik penting: kamu memastikan data yang diproduksi itu lengkap, konsisten, dan terkode dengan benar sebelum dikirim. Data yang rapi di hulu membuat pengiriman di hilir jauh lebih mulus.

🔥 Fakta Menarik: Tenggat RME

Permenkes 24/2022 menetapkan fasilitas pelayanan kesehatan harus menyelenggarakan RME paling lambat 31 Desember 2023. Artinya, di 2026 ini RME bukan lagi “inovasi”, melainkan kewajiban dasar. Kamu bisa cek naskah lengkapnya di JDIH Kemenkes.

⚡ Insight Penting: Satu Kunjungan, Banyak Pemilik Data

Tidak ada satu orang pun yang “memiliki” seluruh RME satu pasien. Karena itu, kualitas data adalah tanggung jawab bersama, dan audit kelengkapan harus melibatkan semua unit, bukan hanya rekam medis.

Siapa yang Mengirim Data dari SIMRS SIMPUS RME?

Pengirimnya adalah sistem, bukan petugas yang mengetik. Setelah data tersimpan, SIMRS atau SIMPUS memanggil layanan pihak lain lewat API (jembatan antaraplikasi). Analoginya kurir ekspedisi: isi paket disiapkan oleh pengirim barang, tapi kurir yang mengantarnya sampai tujuan. Tujuannya antara lain Platform SATUSEHAT milik Kemenkes dan layanan BPJS Kesehatan, yang akan kita bahas di artikel berikutnya.

Agar paket diterima dan dimengerti, formatnya harus seragam. Kemenkes memakai standar HL7 FHIR (Fast Healthcare Interoperability Resources) dari HL7 International. Berikut contoh sederhana data kunjungan dalam format FHIR. Contoh ini disingkat untuk belajar; dokumentasi resmi SATUSEHAT mewajibkan elemen yang lebih lengkap.

📄 contoh-encounter.json

{
  "resourceType": "Encounter",
  "status": "finished",
  "class": { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "AMB", "display": "ambulatory" },
  "subject": { "reference": "Patient/{id-pasien}", "display": "Nama Pasien" },
  "participant": [ { "individual": { "reference": "Practitioner/{id-nakes}" } } ],
  "period": { "start": "2026-11-13T08:00:00+07:00", "end": "2026-11-13T08:25:00+07:00" },
  "serviceProvider": { "reference": "Organization/{id-fasyankes}" }
}

Baca kodenya seperti formulir: subject menunjuk pasien, participant menunjuk tenaga kesehatan, period mencatat waktu, dan serviceProvider menunjuk fasilitas. Setiap kunjungan di SIMRS atau SIMPUS yang dikirim akan dibungkus seperti ini.

⚠️ Perhatian: Pengiriman Gagal Bukan Selalu Salah Jaringan

Data yang tidak lengkap, ID pasien atau tenaga kesehatan yang belum terpetakan, serta kode diagnosis yang tidak valid sering menjadi penyebab penolakan. Jangan langsung menyalahkan server. Periksa kualitas data di hulu dulu.

🛠️ Latihan: Telusuri Satu Kunjungan dari Hulu ke Hilir

1

Pilih satu kunjungan rawat jalan

Pakai kunjungan simulasi atau data anonim dari praktikum. Jangan pernah memakai data pasien asli tanpa izin.

2

Catat siapa yang mengisi tiap data

Buat daftar: pendaftaran, anamnesis, diagnosis, resep, tagihan. Tulis nama unit penginputnya.

3

Tandai tempat data disimpan

Temukan modul SIMRS atau SIMPUS yang menyimpan setiap data tadi.

4

Identifikasi data yang dikirim keluar

Tentukan data mana yang harus sampai ke SATUSEHAT atau BPJS, dan kapan pengiriman dipicu (saat simpan, saat pulang, atau terjadwal).

5

Periksa log dan status pengiriman

Cari data yang berstatus gagal. Catat penyebabnya, lalu tentukan unit mana yang harus memperbaikinya.

Hasil latihan ini bisa kamu jadikan bahan laporan magang: sebuah peta alur data yang menunjukkan siapa memproduksi, siapa mengirim, dan di mana risiko terjadinya.

Ada satu jebakan yang sering muncul di ruang praktikum: orang menyebut “RME” untuk aplikasinya. Akibatnya, vendor, manajemen, dan petugas bicara tentang hal yang berbeda dalam satu rapat. Biasakan dirimu memakai istilah yang tepat, karena istilah yang tepat membuat komunikasi dengan tim IT, manajemen, dan auditor jauh lebih cepat.

Mengapa Pembedaan SIMRS SIMPUS RME Penting untuk Kariermu

Kamu mungkin bertanya, “Kenapa harus serinci ini?” Alasannya praktis. Saat ada keluhan “data tidak masuk”, kamu perlu tahu kepada siapa harus bertanya. Kalau isi data salah, hubungi unit yang menginput. Kalau data benar tapi tidak sampai, hubungi tim pengelola sistem. Kalau sistem lancar tapi tujuan menolak, periksa format dan kredensial integrasi.

Cara berpikir seperti ini juga dipakai dalam audit mutu. Auditor tidak sekadar bertanya “apakah RME sudah ada?”, tapi “apakah data lengkap, siapa yang bertanggung jawab, dan bagaimana jejak pengirimannya?”. Lulusan MIK yang bisa menjawab ketiganya akan terlihat berbeda dari lulusan yang hanya hafal definisi.

⚖️ Analisis: Salah Diagnosis Masalah vs Tepat Diagnosis

❌ Tanpa pembedaan
“Sistemnya error.” Semua pihak saling menunggu, data menumpuk, dan klaim atau pelaporan terlambat.

✅ Dengan pembedaan
“Diagnosis belum terkode di unit rawat jalan, jadi pengiriman ditolak.” Masalah langsung ke unit yang tepat dan selesai lebih cepat.

Terakhir, ingat bahwa pertukaran informasi kesehatan bukan soal teknologi saja. Teknologi hanya mengantar; nilai datanya ditentukan oleh orang yang mencatatnya dan orang yang menjaganya. Di artikel-artikel berikutnya dalam seri ini, kamu akan melihat bagaimana data yang sama mengalir ke klaim JKN, pelaporan program, hingga rekam medis lintas fasilitas.

Satu hal lagi sebelum kamu pindah ke bagian berikutnya: pengiriman data tidak selalu terjadi seketika. Ada sistem yang mengirim saat petugas menekan tombol simpan, ada yang memakai antrean dan mengirim berkala, dan ada yang butuh verifikasi manual lebih dulu. Karena itu, saat kamu menelusuri alur data, tanyakan juga “kapan pengiriman dipicu?” dan “apa yang terjadi kalau gagal?”.

Pertanyaan kedua itu sering terlewat. Sistem yang baik menyimpan log, memberi status jelas, dan menyediakan cara kirim ulang tanpa menggandakan data. Kalau fasilitas tempat kamu magang belum punya mekanisme itu, catat sebagai temuan; itu bahan rekomendasi yang berharga untuk laporanmu.

🎯 Kesimpulan

Tiga poin yang perlu kamu bawa pulang dari pembahasan SIMRS SIMPUS RME:
1. RME adalah isi catatan, sedangkan SIMRS dan SIMPUS adalah sistem tempat catatan itu dikelola.
2. Manusia di fasilitas kesehatan memproduksi data; kamu sebagai perekam medis menjaga kualitasnya.
3. Sistem mengirim data lewat API dengan standar seperti HL7 FHIR, sehingga kualitas data di hulu menentukan keberhasilan di hilir.

Pernah mengalami data gagal terkirim saat praktikum atau magang? Ceritakan di kolom komentar, dan bagikan artikel ini ke teman satu angkatanmu.

💬 Tulis Komentar📤 Bagikan Artikel

📚 Referensi

Kementerian Kesehatan RI. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.
Kementerian Kesehatan RI. (2019). Peraturan Menteri Kesehatan Nomor 31 Tahun 2019 tentang Sistem Informasi Puskesmas.
Kementerian Kesehatan RI. (2013). Peraturan Menteri Kesehatan Nomor 82 Tahun 2013 tentang Sistem Informasi Manajemen Rumah Sakit.
Kementerian Kesehatan RI. (2021). Blueprint Strategi Transformasi Digital Kesehatan 2024.
HL7 International. HL7 FHIR Release 4. hl7.org/fhir.
Naskah regulasi dapat diverifikasi di JDIH Kemenkes (peraturan.go.id dan jdih.kemkes.go.id).

🏷️ Tag

#PertukaranData#PertukaranInformasi#Kesehatan#SIMRS#SIMPUS#RME

📌 Label

SIMRS SIMPUS RMEProdusen dan Pengirim Data KesehatanPertukaran Informasi Kesehatan

📖 Artikel Utama Seri

Pertukaran Informasi Kesehatan

Lihat seluruh daftar isi kuliah D4 MIK dari artikel 1 sampai 16.

Buka Daftar Isi

⬅️ Artikel Sebelumnya

Dari Data Silo ke Satu Data: Kenalan dengan Ekosistem Pertukaran Informasi Kesehatan Indonesia

Artikel Selanjutnya ➡️

Menelusuri Jalur Klaim JKN: Peran P-Care, VClaim, dan E-Klaim INA-CBG

ekosistem pertukaran informasi kesehatan

🏥🔗🏨🔗💻

Seri Pertukaran Informasi Kesehatan · Artikel 1 dari 16

Dari Data Silo ke Satu Data: Kenalan dengan Ekosistem Pertukaran Informasi Kesehatan Indonesia

Peta besar sebelum menyelam ke detail teknis: siapa pemainnya, apa aturan mainnya, dan bagaimana data pasien bisa berpindah dengan aman.

#DataSilo #SATUSEHAT #HL7FHIR #SatuData

⏱ 9 menit

Estimasi baca

🎓 Dasar

Level

📅 2026

Tahun terbit

Pernah dirujuk dari puskesmas ke rumah sakit, lalu diminta mengulang cek darah yang baru kemarin dilakukan? Itu bukan salah perawatnya. Itu gejala data silo: data kesehatan tersimpan rapi, tapi terkunci di sistem masing-masing. Di sinilah ekosistem pertukaran informasi kesehatan berperan, yaitu jaringan sistem, standar, aturan, dan platform yang membuat data pasien berpindah dengan aman dan sah ke tempat yang membutuhkannya.

Sebagai mahasiswa D4 Manajemen Informasi Kesehatan (MIK), kamu kelak jadi orang yang paling sering bersentuhan dengan data itu. Artikel pertama dari seri Pertukaran Informasi Kesehatan ini memberimu peta besarnya. Siap? Kita mulai.

🎯 Target Belajar (Sub-CPMK)

Setelah membaca, kamu mampu:

• menjelaskan ekosistem pertukaran informasi kesehatan dan bedanya dengan data silo;
• mengidentifikasi pelaku dan dasar regulasinya di Indonesia;
• menggambarkan alur data dari sistem fasyankes ke platform nasional berbasis HL7 FHIR.

Apa Itu Ekosistem Pertukaran Informasi Kesehatan? (Mulai dari Analogi Jalan Tol)

Bayangkan tiap kampung membangun jalannya sendiri dengan lebar, rambu, dan aturan yang berbeda. Mobil dari kampung A tidak bisa melaju mulus ke kampung B. Agar kendaraan bisa lintas wilayah, kamu butuh jalan tol nasional dengan pintu tol seragam, aturan lalu lintas, dan operator yang jelas.

Dunia data kesehatan persis begitu. Data pasien adalah kendaraannya, sistem tiap fasilitas adalah kampungnya, platform adalah jalan tolnya, standar data adalah lebar jalannya, dan regulasi adalah rambunya. Kemenkes sendiri menyebut SATUSEHAT sebagai ekosistem pertukaran data kesehatan (Health Information Exchange/HIE) yang menghubungkan sistem atau aplikasi fasilitas pelayanan kesehatan, regulator, penjamin, dan penyedia layanan digital.^[4]

📐 DEFINISI KERJA

Ekosistem Pertukaran Informasi Kesehatan =
Pelaku + Standar + Aturan + Platform
→ data yang tepat sampai ke tempat yang tepat, pada waktu yang tepat.

Rumus ini ringkasan penulis untuk keperluan belajar, disusun dari konsep HIE dan strategi transformasi digital Kemenkes.^[1][4]

🏥

Pelaku

Fasyankes, Kemenkes, penjamin, vendor, pasien

📐

Standar

Format data dan terminologi yang seragam

⚖️

Aturan

Regulasi, hak pasien, pelindungan data

🔌

Platform

Penghubung antarsistem, yaitu SATUSEHAT

💡 Tips: Pakai Kerangka 4 Pertanyaan

Setiap ketemu istilah baru di seri ini, tanyakan: siapa pelakunya, standarnya apa, aturannya apa, platformnya mana? Satu kerangka ini membuat 15 artikel berikutnya terasa seperti variasi dari satu cerita yang sama.

Dari Data Silo ke Satu Data: Kenapa Ekosistem Pertukaran Informasi Kesehatan Dibutuhkan?

Data silo adalah kondisi saat data tersimpan terpisah di banyak sistem yang tidak saling bicara. Masalah ini mendorong Kemenkes menerbitkan Cetak Biru Strategi Transformasi Digital Kesehatan 2024 pada 2021.^[1] Peluncurannya menegaskan pergeseran fokus: dari aplikasi yang sekadar melaporkan untuk pejabat menjadi layanan untuk masyarakat.^[9]

Gambaran masalahnya cukup nyata. Pada 2022, Chief Digital Transformation Office Kemenkes Setiaji menyebut ada sekitar 400 aplikasi kesehatan milik pemerintah yang belum saling terintegrasi, sehingga data yang sama dikumpulkan berulang oleh aplikasi berbeda. Ketidakseragaman metadata dan tidak adanya standar format interoperabilitas membuat integrasi dikerjakan dengan cara berbeda-beda.^[5]

SEBELUM (data silo)           SESUDAH (satu data)

[Puskesmas]  [Klinik]         [Puskesmas]--\
     X           X                           \
[  RS  ]     [  Lab ]         [Klinik]------[PLATFORM]---[RS Rujukan]
                                             /
Tiap kotak = sistem sendiri   [Lab]---------/

🔍 Analisis Kasus: Pasien Rujukan

❌ Dengan data silo
Puskesmas mencatat di sistem A, pasien membawa kertas, RS menginput ulang di sistem B, lab diulang. Hasilnya data ganda, risiko salah ketik, dan waktu terbuang.

✅ Dengan ekosistem terhubung
Puskesmas mengirim data ke platform. RS rujukan mengakses riwayat sesuai persetujuan pasien, karena Permenkes 24/2022 memberi fasyankes rujukan hak akses atas persetujuan tersebut.^[2]

Aspek	Data Silo	Ekosistem Terintegrasi
Format data	Beda tiap sistem	Seragam (standar bersama)
Input data	Berulang di banyak tempat	Sekali catat, banyak pemakai
Riwayat pasien	Terpecah per fasilitas	Dapat dilihat lintas fasyankes (dengan persetujuan)
Dasar kebijakan	Data parsial	Data lebih komprehensif

🔥 Fakta Menarik: Punya RME Belum Tentu Terhubung

Berdasarkan dashboard SATUSEHAT per 7 Maret 2024, sebanyak 2.956 rumah sakit sudah memiliki rekam medis elektronik, tetapi baru 1.862 yang mengirim data ke SATUSEHAT.^[6] Itu sekitar 63% (hitungan penulis). Artinya, digitalisasi dan interoperabilitas adalah dua pekerjaan berbeda.

Lalu, apa urusannya denganmu? Banyak. Lulusan MIK bekerja di titik pertama data lahir: pendaftaran, pengodean diagnosis, dan pelaporan. Kalau kamu salah menulis identitas atau salah memilih kode, kesalahan itu tidak berhenti di satu komputer. Ia ikut terkirim ke sistem lain dan bisa dibaca dokter di fasilitas berbeda. Jadi, kualitas pekerjaan rekam medismu sekarang menentukan seberapa layak data kita dipercaya setelah terhubung. Anggap saja kamu penjaga gerbang tol: kendaraan boleh banyak, tapi yang lewat harus lengkap dan benar.

Peta Pemain dan Aturan Main Ekosistem Pertukaran Informasi Kesehatan di Indonesia

Siapa saja pemainnya? Ada fasyankes (rumah sakit, puskesmas, klinik, laboratorium), penyedia aplikasi RME, Kemenkes sebagai pengelola platform, penjamin, dan masyarakat yang mengakses datanya lewat SATUSEHAT Mobile.^[4] Kemenkes meminta seluruh fasyankes dan penyedia RME mendaftar serta tergabung dalam SATUSEHAT Platform.^[10]

Apa aturan mainnya? Berikut regulasi inti yang wajib kamu kenal. Daftar ini mengacu pada bagian "Mengingat" Surat Edaran Menkes 1030/2023 dan dokumen Kemenkes lain.

Regulasi	Peran dalam ekosistem
UU No. 17/2023 tentang Kesehatan	Payung hukum kesehatan terbaru, termasuk sistem informasi kesehatan
PP No. 46/2014 tentang Sistem Informasi Kesehatan	Dasar penyelenggaraan sistem informasi kesehatan
Permenkes No. 18/2022 tentang Satu Data Bidang Kesehatan	Tujuan akhir: satu data kesehatan lewat sistem informasi kesehatan
Permenkes No. 24/2022 tentang Rekam Medis	Mewajibkan RME paling lambat 31 Desember 2023; menggantikan Permenkes 269/2008
SE Menkes HK.02.01/MENKES/1030/2023	Penyelenggaraan RME, integrasi SATUSEHAT, dan sanksi administratif
UU No. 27/2022 tentang Pelindungan Data Pribadi	Data rekam medis diperlakukan sebagai data pribadi spesifik

Sumber ringkasan: [2][3][11][12]

⚡ Insight Penting: Tiga Peran yang Jangan Ketukar

Satu Data adalah tujuannya. RME adalah sumber datanya. SATUSEHAT adalah jalur penghubungnya. Banyak mahasiswa mengira RME dan SATUSEHAT itu sama. Padahal RME hidup di fasyankes, sedangkan SATUSEHAT menghubungkan RME dari banyak fasyankes.

⚠️ Perhatian: Data Pasien Bukan Konten Tugas

Data rekam medis tergolong data pribadi spesifik.^[3] Jangan unggah tangkapan layar data pasien ke grup WhatsApp atau media sosial, bahkan untuk bahan tugas. Gunakan data fiktif atau data yang sudah dianonimkan.

Bagaimana Ekosistem Pertukaran Informasi Kesehatan Bekerja? Alur Data dengan HL7 FHIR

Aturan dan platform saja belum cukup. Data harus "berbahasa" sama. Untuk itu, protokol integrasi data SATUSEHAT menggunakan HL7 FHIR (Fast Healthcare Interoperability Resources), dan setiap sistem RME wajib mampu berinteroperabilitas dengan platform tersebut.^[7] FHIR dikembangkan HL7 International dan memecah informasi kesehatan menjadi "resource" berformat standar.^[8]

Analogi gampangnya: FHIR itu seperti formulir baku. Apa pun merek sistemmu, selama kamu mengisi formulir yang sama dengan cara yang sama, penerima di ujung sana langsung paham.

Data yang kamu kenal	Resource FHIR	Contoh isi
Identitas pasien	Patient	NIK, nama, tanggal lahir
Kunjungan	Encounter	Rawat jalan/inap, waktu layanan
Diagnosis	Condition	Kode ICD-10
Tanda vital, hasil lab	Observation	Tekanan darah, hasil laboratorium

Lima Langkah Perjalanan Data

1

Catat di sistem internal. Tenaga kesehatan menginput layanan ke SIMRS, SIMPUS, atau RME fasyankes.

2

Petakan ke resource FHIR. Sistem mengubah data lokal menjadi resource seperti Patient dan Condition, lengkap dengan terminologi standar.

3

Buktikan identitas sistem. Fasyankes yang sudah terdaftar memakai kredensial resminya untuk memperoleh izin akses (token) dari platform.

4

Kirim lewat REST API. Data berformat JSON dikirim lewat permintaan HTTP ke platform.

5

Platform menyimpan, pihak berhak mengakses. Pasien dan fasyankes rujukan dapat mengakses data sesuai persetujuan pasien.^[2]

patient.json — contoh ilustrasi

{
  "resourceType": "Patient",
  "identifier": [{
    "use": "official",
    "system": "https://fhir.kemkes.go.id/id/nik",
    "value": "3171000000000001"
  }],
  "active": true,
  "name": [{ "use": "official", "text": "Budi Contoh" }],
  "gender": "male",
  "birthDate": "1990-01-15"
}

Catatan: data di atas fiktif dan hanya ilustrasi struktur. Untuk payload, alamat endpoint, dan sistem identifier yang berlaku, selalu rujuk dokumentasi resmi di portal SATUSEHAT.^[7]

Perhatikan satu hal penting dari alur tadi: format yang benar belum menjamin isi yang benar. Platform bisa menerima JSON yang rapi, tetapi tidak bisa tahu bahwa kamu salah mengeja nama pasien atau keliru memilih kode ICD-10. Di sinilah peranmu sebagai profesional MIK. Biasakan memeriksa kelengkapan, konsistensi, dan ketepatan data sebelum dikirim. Pemeriksaan sepuluh detik di awal sering menghemat berjam-jam perbaikan di akhir. Di artikel-artikel berikutnya, kita bedah satu per satu bagian alur ini, mulai dari sistem sumbernya.

💡 Tips: Misi 15 Menit Minggu Ini

Ambil kertas, lalu gambar peta sistem informasi di tempat praktik atau magangmu: sistem apa saja yang dipakai, siapa penginputnya, dan apakah datanya terkirim ke luar. Kalau belum tahu, tanya pembimbing lapangan. Peta sederhana ini jadi bahan diskusi kelas berikutnya.

🏁 Kesimpulan

Ekosistem pertukaran informasi kesehatan adalah gabungan pelaku, standar, aturan, dan platform yang mengubah data silo menjadi satu data. Ringkasnya:

• Data silo membuat data ganda, riwayat terpecah, dan kebijakan kurang berbasis data.
• Permenkes 24/2022 dan SE 1030/2023 mendorong RME terintegrasi dengan SATUSEHAT.
• HL7 FHIR adalah "bahasa bersama" yang membuat sistem berbeda saling paham.
• Punya RME belum cukup; data harus benar-benar mengalir, dengan menjaga privasi pasien.

Itulah peta besar ekosistem pertukaran informasi kesehatan Indonesia. Artikel berikutnya masuk ke para produsen datanya.

Di tempat praktikmu, data pasien masih silo atau sudah terhubung? Ceritakan di kolom komentar, dan bagikan artikel ini ke teman satu angkatan!

💬 Tulis Komentar 🔗 Bagikan via WhatsApp

📚 Referensi

1. Kementerian Kesehatan RI. (2021). Cetak Biru Strategi Transformasi Digital Kesehatan 2024. Jakarta. repository.kemkes.go.id/book/710
2. Kementerian Kesehatan RI. (2022, 9 September). Fasyankes Wajib Terapkan Rekam Medis Elektronik. kemkes.go.id
3. Menteri Kesehatan RI. (2023). Surat Edaran No. HK.02.01/MENKES/1030/2023 tentang Penyelenggaraan Rekam Medis Elektronik di Fasyankes serta Penerapan Sanksi Administratif. jdih.kemkes.go.id
4. Kementerian Kesehatan RI. (2024, 31 Oktober). SATUSEHAT Dikembangkan Langsung oleh Kemenkes. kemkes.go.id
5. Bisnis.com. (2022, 25 April). Kemenkes Luncurkan Sistem Kesehatan Satu Pintu, Ini Tujuannya. kabar24.bisnis.com
6. Ditjen Kesehatan Lanjutan, Kemenkes RI. (2024, 7 Maret). Desk Sistem Informasi Rumah Sakit, RME dan SATUSEHAT. keslan.kemkes.go.id
7. Kementerian Kesehatan RI. Surat Edaran tentang Penyelenggaraan Rekam Medis Elektronik yang Terinteroperabilitas dengan Platform SATUSEHAT. keslan.kemkes.go.id; portal: satusehat.kemkes.go.id/platform
8. HL7 International. FHIR Overview. hl7.org/fhir
9. Kementerian Kesehatan RI. (2021, 16 Desember). Strategi Transformasi Digital Kesehatan 2024 Diluncurkan, Fokus ke Pelayanan Kesehatan bukan Pelaporan untuk Pejabat. kemkes.go.id
10. Kementerian Kesehatan RI. (2023, 4 September). Begini Cara Terintegrasi ke SATUSEHAT bagi Fasyankes dan Penyedia Rekam Medis Elektronik. kemkes.go.id
11. Republik Indonesia. UU No. 17 Tahun 2023 tentang Kesehatan; PP No. 46 Tahun 2014 tentang Sistem Informasi Kesehatan; UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (dirujuk dalam bagian "Mengingat" SE No. HK.02.01/MENKES/1030/2023).
12. Menteri Kesehatan RI. Permenkes No. 24 Tahun 2022 tentang Rekam Medis (pengganti Permenkes No. 269/2008) dan Permenkes No. 18 Tahun 2022 tentang Penyelenggaraan Satu Data Bidang Kesehatan melalui Sistem Informasi Kesehatan. Akses melalui jdih.kemkes.go.id.

🏷️ Tag

#PertukaranData #PertukaranInformasi #Kesehatan #EkosistemPertukaranInformasiKesehatan

📂 Label

Pertukaran Informasi Kesehatan Ekosistem Pertukaran Informasi Kesehatan Dari Data Silo ke Satu Data D4 MIK

📘 ARTIKEL UTAMA SERI

Pertukaran Informasi Kesehatan

Daftar isi lengkap kuliah D4 MIK: 16 artikel dari fondasi sampai praktik.

Buka Daftar Isi Kuliah →

← ARTIKEL SEBELUMNYA

Tidak ada. Ini artikel pertama dalam seri. 🎉

ARTIKEL SELANJUTNYA →

SIMRS, SIMPUS, dan RME: Siapa yang Memproduksi Data dan Siapa yang Mengirimnya?