Bridging SatuSehat dan V-Claim BPJS: Panduan Lengkap RS 2026

Ringkasan: Bridging SatuSehat dan V-Claim BPJS adalah praktik menghubungkan rekam medis elektronik rumah sakit ke dua sistem nasional sekaligus: platform interoperabilitas Kemenkes (HL7 FHIR R4) dan ekosistem klaim BPJS Kesehatan (V-Claim 2.0). Tujuannya: pelaporan otomatis ke SatuSehat untuk kepatuhan PMK 24/2022, dan pengajuan klaim ke BPJS tanpa input ulang. Artikel ini mengurai arsitektur, contoh JSON FHIR, sepuluh pitfall implementasi, serta FAQ untuk Direktur RS, Kepala Casemix, dan Tim IT.

Mengapa Dua Sistem Ini Perlu Di-Bridge

Rumah sakit di Indonesia menjalankan dua kewajiban data yang berjalan paralel namun berdiri di atas standar yang sangat berbeda. Di satu sisi, Kemenkes mewajibkan integrasi data klinis ke platform SatuSehat menggunakan standar HL7 FHIR R4. Di sisi lain, BPJS Kesehatan menuntut pengajuan klaim, rujukan, dan monitoring kunjungan melalui ekosistem V-Claim 2.0 yang memakai enkripsi AES-256-CBC dan kompresi LZ-string. Tanpa bridging, tim koding harus mengetik ulang data yang sama dua kali dengan kemungkinan inkonsistensi yang besar.

Beban operasional ini bukan teori. Audit BPK 2023 hingga Juni 2024 menemukan klaim BPJS bermasalah senilai Rp 1,45 triliun dengan 1,02 juta SEP terindikasi dan 611.340 di antaranya belum direviu pasca-klaim. Pada Oktober 2024, Tempo melaporkan dua juta kasus klaim mandek (naik 280% dari Januari). Rata-rata pembayaran klaim FKRTL pada 2024 berada di angka 13,62 hari kalender — durasi yang langsung membebani arus kas rumah sakit kecil dan menengah.

"Kalau BPJS Kesehatan terus melakukan pending selama 3 bulan berturut-turut, rumah sakit pasti akan kolaps."

— Direktur RS swasta Riau · Tempo, Februari 2025

"Kami hampir betul-betul tenggelam. Anggaran habis untuk makan bergizi gratis."

— Iing Ichsan Hanafi, Ketua Umum ARSSI · Tempo, 4 Februari 2025

Pada saat yang sama, PMK 24/2022 Pasal 21 mewajibkan fasilitas pelayanan kesehatan menjamin interoperabilitas RME dengan platform yang ditetapkan Menteri (SatuSehat). Pasal 41 mengatur sanksi administratif berjenjang bagi fasyankes yang tidak memenuhi kewajiban dokumentasi dan interoperabilitas. Bridging yang rapi bukan sekadar efisiensi — ia adalah bagian dari kepatuhan regulasi sekaligus penyangga arus kas.

Tabel Komparasi: SatuSehat vs V-Claim BPJS

Banyak Direktur RS memperlakukan kedua sistem seolah satu kategori yang sama. Padahal regulator, standar data, dan model otentikasinya berbeda total. Memahami perbedaan ini menjelaskan kenapa bridging memerlukan satu lapisan terjemahan tersendiri, bukan sekadar konektor langsung.

Aspek	SatuSehat	V-Claim BPJS
Regulator	Kemenkes (Digital Transformation Office)	BPJS Kesehatan
Standar data	HL7 FHIR R4 (JSON)	REST custom dengan AES-256-CBC + LZ-string
Identifier inti	NIK + IHS Number	Nomor Kartu BPJS / NIK
Endpoint produksi	api-satusehat.kemkes.go.id	apijkn.bpjs-kesehatan.go.id/vclaim-rest
Otentikasi	OAuth2 client_credentials	HMAC-SHA256 signature + Basic + cons-id
Resource utama	Patient, Encounter, Condition, Procedure, ImagingStudy, MedicationRequest, Observation, dst (12+ resource FHIR)	Peserta, SEP, Klaim, Rujukan, Monitoring, PRB
Frekuensi push	Real-time per kunjungan klinis	Per encounter klinis (rawat jalan, rawat inap, IGD)
Dasar wajib	PMK 24/2022 Pasal 21	Per RS yang menandatangani kontrak BPJS Kesehatan
Output	Bundle FHIR (transaction/document)	JSON terenkripsi terkompresi
Token TTL	3.599 detik (~1 jam)	Per request (timestamp UNIX seconds)

Tabel ini sengaja diletakkan di awal karena banyak kesalahan implementasi berakar pada asumsi keliru bahwa "satu standar pasti cocok untuk dua sistem". Misalnya, format ICD-10 di SatuSehat memakai konvensi WHO penuh (A09.0), sedangkan BPJS V-Claim menerima format pendek (A09). Bridging hub yang dirancang baik akan memetakan terjemahan ini secara otomatis.

Arsitektur Bridging 3-Layer

Bridging yang berhasil hampir selalu memakai pola tiga lapis: lapisan sumber data, lapisan terjemahan dan orkestrasi, lapisan target. Pola ini sudah jadi praktik yang umum di industri integrasi data klinis Indonesia karena memisahkan tanggung jawab dengan jelas dan menyederhanakan audit.

┌─────────────────────────────────────────┐
│  LAYER 1 — SIMRS / RME Rumah Sakit       │
│  (sumber data klinis dan administratif)  │
│  - Pendaftaran, diagnosa, prosedur       │
│  - Hasil lab, radiologi, resep           │
│  - Data peserta BPJS, SEP, klaim         │
└────────────────┬────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────┐
│  LAYER 2 — Integration Hub               │
│  (terjemahan + tanda tangan + retry)     │
│  - Mapping internal -> FHIR R4           │
│  - HMAC SHA-256 signing untuk V-Claim    │
│  - OAuth2 token cache untuk SatuSehat    │
│  - Antrean retry (queue + dead letter)   │
│  - Audit log lengkap per resource        │
└────────┬───────────────────┬────────────┘
         │                   │
         ▼                   ▼
┌──────────────────┐  ┌──────────────────┐
│  LAYER 3 (a)      │  │  LAYER 3 (b)      │
│  SatuSehat        │  │  V-Claim BPJS     │
│  api-satusehat... │  │  apijkn.bpjs-...  │
└──────────────────┘  └──────────────────┘

Lapisan tengah ini sering tidak terlihat oleh pengguna akhir, tapi dialah yang menentukan rasa stabil tidaknya integrasi. Tanpa hub di tengah, tim IT rumah sakit harus mengelola kredensial OAuth2 SatuSehat sekaligus pasangan cons-id, cons-secret, dan user_key BPJS langsung dari kode SIMRS — lengkap dengan kerumitan refresh token dan rotasi signing key. Setiap kali Kemenkes atau BPJS merilis breaking change pada API, SIMRS harus di-deploy ulang.

Ada tiga alasan teknis mengapa hub di tengah sangat dianjurkan:

Single credential management. Kredensial dua sistem hanya disimpan di satu titik dengan rotasi terkontrol. Tim klinis dan tim IT SIMRS tidak pernah memegang client_secret SatuSehat atau cons_secret BPJS.
Error retry dan backpressure. Saat SatuSehat atau BPJS lambat, antrean di hub menahan permintaan agar SIMRS tidak ikut macet. Ini krusial pada jam sibuk poliklinik.
Audit log seragam. Tim verifikator internal dan auditor eksternal (BPK, Inspektorat) bisa membaca jejak push FHIR dan signature V-Claim dalam satu format. Ini sangat membantu saat menelusuri mengapa sebuah klaim ditolak.

MedMinutes Integration Hub mengikuti pola tiga lapis ini. Hub ini bekerja berdampingan dengan SIMRS yang sudah ada — bukan menggantikannya. MedMinutes adalah RME plus Integration Hub, bukan SIMRS billing-inventori-HR.

Demo Gratis 30 Menit

Lihat langsung berapa
revenue RS Anda yang bocor

Dalam 30 menit, kami analisis data klaim RS Anda — langsung di depan Anda.

Jadwalkan Demo→

Tanpa biaya, tanpa kewajiban

Delapan Contoh JSON Bundle yang Sering Dipakai

Bagian ini berisi delapan contoh kode yang paling sering dibutuhkan saat memulai bridging. Embed lengkap supaya tim teknis bisa langsung menyalin, membandingkan dengan implementasi internal, dan memetakan field yang rawan error.

1. OAuth2 Token Request — SatuSehat

Setiap panggilan ke SatuSehat memerlukan bearer token yang berlaku 3.599 detik. Token didapatkan dari endpoint OAuth2 dengan grant type client_credentials. Jika token kedaluwarsa di tengah pengiriman batch, response akan 401 dan resource yang sedang dikirim harus di-retry setelah refresh.

curl --insecure --location \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<client-id>' \
  --data-urlencode 'client_secret=<client-secret>' \
  --request POST \
  'https://api-satusehat-stg.dto.kemkes.go.id/oauth2/v1/accesstoken?grant_type=client_credentials'

Response berisi access_token, token_type (BearerToken), expires_in (3.599), issued_at, dan organization_name (ihs-prod-1 untuk produksi). Base URL produksi adalah https://api-satusehat.kemkes.go.id. Pitfall paling umum: aplikasi merefresh token setiap request — boros panggilan, kena rate limit. Solusinya cache token dengan TTL 50 menit (lebih pendek dari 60 menit untuk margin aman).

Sumber: Dokumentasi Token SatuSehat

2. Patient Resource (FHIR R4)

Resource Patient adalah pintu masuk pertama setiap encounter. Identifier wajib mencakup NIK plus IHS Number (kalau pasien sudah pernah terdaftar di SatuSehat). Field name.text wajib diisi karena banyak konsumen FHIR Indonesia memakai field tersebut sebagai display utama.

{
  "resourceType": "Patient",
  "identifier": [
    {
      "use": "official",
      "system": "https://fhir.kemkes.go.id/id/nik",
      "value": "9271060312000001"
    },
    {
      "use": "official",
      "system": "https://fhir.kemkes.go.id/id/patient-ihs-number",
      "value": "P02478375538"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "text": "Ardianto Putra",
      "family": "Putra",
      "given": ["Ardianto"]
    }
  ],
  "telecom": [{ "system": "phone", "value": "08123456789", "use": "mobile" }],
  "gender": "male",
  "birthDate": "1992-01-09"
}

Pitfall yang paling sering bikin RS terhambat: birthDate di bawah tanggal 03 Juni 2014 ditolak server validasi tertentu, dan extension administrativeCode wajib memakai kode BPS resmi (bukan sekadar nama desa atau kelurahan).

Sumber: Dokumentasi Patient SatuSehat

3. Encounter Resource (FHIR R4)

Encounter adalah resource yang menghubungkan pasien, praktisi, dan periode kunjungan. Banyak resource klinis lain (Condition, Procedure, ImagingStudy) merujuk ke Encounter, jadi resource ini biasanya diunggah lebih dulu setelah Patient.

{
  "resourceType": "Encounter",
  "status": "finished",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "AMB",
    "display": "ambulatory"
  },
  "subject": { "reference": "Patient/100000030009" },
  "participant": [{ "individual": { "reference": "Practitioner/N10000001" } }],
  "period": {
    "start": "2023-08-23T03:35:00+00:00",
    "end": "2023-08-23T04:15:00+00:00"
  },
  "statusHistory": [
    {
      "status": "arrived",
      "period": {
        "start": "2023-08-23T03:30:00+00:00",
        "end": "2023-08-23T03:35:00+00:00"
      }
    },
    {
      "status": "in-progress",
      "period": {
        "start": "2023-08-23T03:35:00+00:00",
        "end": "2023-08-23T04:10:00+00:00"
      }
    },
    {
      "status": "finished",
      "period": {
        "start": "2023-08-23T04:10:00+00:00",
        "end": "2023-08-23T04:15:00+00:00"
      }
    }
  ],
  "serviceProvider": { "reference": "Organization/{organization-ihs-number}" }
}

Pitfall yang paling rawan: timestamp wajib UTC+00 (kurangi 7 jam dari WIB) dan statusHistory minimal tiga transisi (arrived -> in-progress -> finished). Banyak SIMRS hanya mengirim status terakhir tanpa rekaman antrean — server validasi menolaknya.

Sumber: Dokumentasi Encounter SatuSehat

4. Condition Resource (ICD-10)

Condition mengirim diagnosa kerja, sementara, atau definitif. Format ICD-10 di SatuSehat wajib memakai standar WHO penuh, termasuk sub-kode setelah titik desimal.

{
  "resourceType": "Condition",
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "https://www.hl7.org/fhir/Codesystem-condition-ver-status",
        "code": "provisional"
      }
    ]
  },
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/condition-category",
          "code": "encounter-diagnosis"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://hl7.org/fhir/sid/icd-10",
        "code": "C47.0",
        "display": "Malignant neoplasm, peripheral nerves of head, face and neck"
      }
    ]
  },
  "subject": { "reference": "Patient/100000030009" },
  "encounter": {
    "reference": "Encounter/2b2d0a3e-082a-4fe9-ae13-da9c3b5e422f"
  },
  "onsetDateTime": "2022-12-20T10:35:00+00:00"
}

Pitfall yang sering bikin push gagal: ICD-10 dikirim dalam format BPJS (A09) — SatuSehat akan menolaknya karena WHO mengharuskan sub-kode (A09.0). Bridging hub harus menormalkan kode sebelum push.

Sumber: Dokumentasi Condition SatuSehat

5. ImagingStudy Resource (DICOM)

Resource ImagingStudy adalah jembatan dari modality radiologi ke FHIR. Field modality wajib memakai DICOM Code System resmi, bukan kode internal vendor PACS.

{
  "resourceType": "ImagingStudy",
  "identifier": [
    {
      "system": "http://sys-ids.kemkes.go.id/acsn/10000004",
      "value": "210610114146"
    }
  ],
  "status": "available",
  "modality": [
    {
      "system": "http://dicom.nema.org/resources/ontology/DCM",
      "code": "CT",
      "display": "Computed Tomography"
    }
  ],
  "subject": [{ "reference": "Patient/100000030009" }],
  "encounter": [
    { "reference": "Encounter/0a26ca28-0ea3-486d-8fa9-6f9edd37e567" }
  ],
  "started": "2021-06-10T11:41:46+07:00",
  "series": [
    {
      "uid": "1.2.48.670589.30.39.0.1.966169786508.1664950724077.1",
      "modality": {
        "system": "http://dicom.nema.org/resources/ontology/DCM",
        "code": "CT"
      },
      "numberOfInstances": 1,
      "instance": [
        {
          "uid": "2.16.380.31256.1.2449191199178232.20210610114930875.1.1",
          "number": 7
        }
      ]
    }
  ]
}

Pitfall paling sering: tim PACS mengirim modality kode internal vendor; SatuSehat hanya menerima DICOM Code System (CT, MR, CR, US, OP, XA, MG, dst). MedMinutes bukan vendor PACS — kami melakukan integrasi data DICOM ke SatuSehat lewat DICOM Router native Kemenkes.

Sumber: Dokumentasi ImagingStudy SatuSehat

6. DICOM Router Native Kemenkes

Kemenkes menyediakan DICOM Router resmi yang berjalan sebagai container Docker di server rumah sakit. Router ini bertindak sebagai DIMSE listener — modality CT, MRI, CR mengarahkan output C-STORE ke port 11112 router, lalu router yang mengirim ke SatuSehat. Hingga akhir 2025, tiga puluh rumah sakit sudah sukses pilot dan jumlah fasyankes yang sudah aktif di Cluster Resource 6 (Observasi dan Radiologi) tercatat 10.619.

curl -H "Authorization: Bearer <access-token>" \
  https://api-satusehat-stg.dto.kemkes.go.id/dicom-router \
  -o docker-compose.zip
unzip docker-compose.zip && cd dicom-router

cat <<EOF > .env
ORG_ID=<organization-id-satusehat>
CLIENT=<client-id-satusehat>
SECRET=<client-secret-satusehat>
URL=https://api-satusehat-stg.dto.kemkes.go.id
EOF

docker compose up -d

Port 11112:11112 adalah DIMSE listener untuk target C-STORE modality. Pitfall: tim IT lupa membuka firewall internal antara modality dan server router, atau memakai modality kode internal yang tidak ada di whitelist DICOM.

Sumber: Dokumentasi DICOM Router SatuSehat

7. V-Claim Signature Generation (TypeScript)

Setiap request V-Claim memerlukan tiga header: X-cons-id, X-timestamp, X-signature, plus user_key. Signature dihitung dengan HMAC-SHA256 atas string cons_id&timestamp memakai cons_secret sebagai kunci, lalu di-base64 dan di-encode URI.

import { createHmac } from "node:crypto";

function getDefaultHeaders(
  consId: string,
  consSecret: string,
  userKey: string,
) {
  const timestamp = Math.round(Date.now() / 1000);
  const message = `${consId}&${timestamp}`;
  const signature = createHmac("SHA256", consSecret)
    .update(message)
    .digest("base64");
  return {
    "X-cons-id": consId,
    "X-timestamp": String(timestamp),
    "X-signature": encodeURI(signature),
    user_key: userKey,
  };
}
// Base URL: https://apijkn.bpjs-kesehatan.go.id/vclaim-rest

Pitfall paling klasik: signature lupa di-encodeURI() sehingga karakter + jadi spasi — BPJS langsung menolak dengan pesan Invalid Signature. Pitfall kedua: timestamp dikirim dalam milidetik, bukan UNIX seconds. Pitfall ketiga: cons_id atau cons_secret terbawa whitespace saat copy-paste dari email konfirmasi BPJS.

Sumber: Library ssecd/jkn

8. V-Claim Response Decryption (PHP, AES-256-CBC + LZ-string)

Response V-Claim datang sebagai string yang dienkripsi AES-256-CBC dan dikompresi LZ-string. Kunci enkripsi diturunkan dari cons_id . secret_key . X-timestamp dari request asli — bukan timestamp baru saat decrypt.

class GenerateBpjs {
    const ENCRYPT_METHOD = 'AES-256-CBC';

    public static function stringDecrypt($key, $string) {
        $key_hash = hex2bin(hash('sha256', $key));
        $iv = substr($key_hash, 0, 16);
        return openssl_decrypt(
            base64_decode($string), self::ENCRYPT_METHOD,
            $key_hash, OPENSSL_RAW_DATA, $iv
        );
    }
}

// Usage:
$key = $consId . $secretKey . $timestamp;
$decrypted = GenerateBpjs::stringDecrypt($key, $response['response']);
$json = LZCompressor\LZString::decompressFromEncodedURIComponent($decrypted);
$data = json_decode($json, true);

Pitfall paling halus: timestamp untuk derive key wajib pakai X-timestamp dari request asli. Kalau aplikasi memanggil time() lagi saat decrypt, kuncinya berbeda dan output decrypt jadi gibberish. IV adalah 16 byte pertama dari hash SHA-256 key, bukan random.

Sumber: Library virusphp/bridging-bpjs

Delapan blok di atas adalah inti praktis bridging. Kalau tim IT rumah sakit menguasai delapan ini saja, separuh pekerjaan integrasi sudah kelar.

Compliance Roadmap: Timeline Regulasi 2022 hingga 2027

Bridging tidak berdiri sendiri — ia mengikuti jadwal regulasi yang terus berubah. Berikut timeline kunci yang perlu dipantau Direktur RS dan Tim Compliance.

31 Agustus 2022 — PMK 24/2022 berlaku. Permenkes 24/2022 tentang Rekam Medis menjadi landasan: RME wajib elektronik, dengan deadline kepatuhan sampai 31 Desember 2023.

2024 — Surat Edaran Kemenkes pengunduran. Kemenkes mengeluarkan kebijakan pengunduran target kepatuhan ke akhir 2025, mengakui banyak fasyankes belum siap infrastruktur. Per Oktober 2025, BKPK Kemenkes melaporkan 34.463 fasyankes terintegrasi SatuSehat dan 3.138 dari 3.239 RS (96,9%) sudah implementasi RME — namun 495 RS belum melengkapi enam layanan inti.

2023 — UU 17/2023 Kesehatan disahkan. Menjadi payung hukum baru kesehatan nasional, mengonsolidasikan banyak peraturan sebelumnya dan memperkuat amanat interoperabilitas data.

2026 — KMK 62/2026 STARKES. Standar Akreditasi Rumah Sakit (STARKES) menggantikan SNARS, dengan enam Lembaga Independen Penyelenggara Akreditasi (LIPA). Bab MRMIK (Manajemen Rekam Medis dan Informasi Kesehatan) menempatkan integrasi SatuSehat sebagai elemen penilaian.

1 April 2026 — INA-CBG 5.9 berlaku. INA-CBG versi 5.9 menjadi tarif berlaku pasca Perpres 59/2024. Versi ini menjadi titik transisi menuju iDRG (Indonesian Diagnosis Related Groups) dengan target 1.300+ groups dan lima level severity, dijadwalkan rampung 2025 hingga 2027.

Cluster Resource SatuSehat — rollout bertahap. Kemenkes membagi resource SatuSehat menjadi 12 cluster. Saat ini cluster 1 hingga 5 sudah rilis penuh (Patient, Encounter, Condition, Procedure, MedicationRequest, Observation, dll), cluster 6 (Observasi dan Radiologi termasuk ImagingStudy) sedang aktif disosialisasikan. Cluster 7 ke atas masih bertahap. Setiap penambahan cluster menambah daftar resource yang wajib di-bridge.

Bridging yang benar adalah bridging yang tahan terhadap perubahan timeline ini. Hub yang fleksibel dapat menambahkan resource baru tanpa harus mengubah SIMRS, dan dapat mendukung versi INA-CBG yang berbeda (5.8 lama, 5.9 baru) sampai transisi iDRG selesai.

Sepuluh Pitfall Implementasi yang Sering Bikin Rumah Sakit Gagal

Daftar berikut diramu dari pengalaman implementasi nyata di puluhan rumah sakit. Cek setiap poin sebelum go-live, idealnya dengan tim QA internal.

NIK validation cutoff. Server validasi tertentu menolak birthDate di bawah 03 Juni 2014 untuk pasien anak. Pastikan logic mapping menangani kasus ini sebelum push, misalnya dengan menandai pasien anak melalui field extension daripada birthDate mentah.
IHS Number duplication. Saat integrasi awal, sistem sering membuat IHS Number baru padahal pasien sudah pernah terdaftar. Selalu lakukan match Patient dengan NIK lebih dulu sebelum membuat resource baru.
Signature timestamp UTC vs WIB. Tanda tangan V-Claim memakai UNIX seconds tanpa timezone. SatuSehat justru memakai timestamp UTC eksplisit. Tim yang mengirim WIB ke SatuSehat akan melihat encounter berpindah tujuh jam.
HMAC base64 lupa encodeURI. Karakter + di hasil base64 jadi spasi saat dikirim sebagai header HTTP. BPJS langsung menolak dengan Invalid Signature. Wajib encodeURI() setelah base64.
AES key derivation memakai timestamp baru. Saat decrypt response V-Claim, timestamp untuk key derivation wajib pakai X-timestamp dari request asli. Banyak implementasi memakai time() baru — hasil decrypt jadi byte acak.
ICD-10 format BPJS vs WHO. BPJS menerima A09; SatuSehat menolaknya dan minta A09.0. Bridging hub wajib memetakan kode ke format target sebelum push.
Encounter statusHistory kurang dari tiga transisi. SatuSehat mengharapkan arrived, in-progress, finished minimal. SIMRS yang hanya menyimpan status terakhir akan ditolak validator.
DICOM modality kode internal vendor. Output PACS sering memakai kode Siemens/GE internal. SatuSehat hanya menerima DICOM Code System (CT, MR, CR, US, OP). Bridging hub wajib mapping ulang.
Token TTL 1 jam. OAuth2 SatuSehat memberikan token berlaku 3.599 detik. Jangan refresh setiap request (boros) tapi juga jangan biarkan expired di tengah batch (gagal). Cache dengan TTL 50 menit aman.
serviceProvider reference. Field serviceProvider di Encounter wajib mereferensikan IHS Number Master Sarana, bukan nama RS atau ID internal. Salah satu kesalahan paling halus karena lolos validasi tipe data tapi ditolak validasi referensial.

Daftar ini cocok dijadikan checklist dinding tim IT sebelum go-live, dan dijadikan kriteria smoke test setiap kali ada perubahan kode pada lapisan bridging.

Studi Kasus Singkat (Anonim)

Sebuah rumah sakit tipe C di Jawa Tengah dengan 50+ tempat tidur menghadapi situasi yang akrab bagi banyak rumah sakit menengah. Sebelum bridging dipasang, sekitar 30% klaim BPJS-nya pending karena ketidakcocokan kode atau kelengkapan dokumen, dan tim casemix harus login dashboard SatuSehat manual untuk mengentri data observasi dan radiologi setiap akhir hari. Tim koding mengeluh karena harus mengetik diagnosa yang sama dua kali — satu di SIMRS, satu di SatuSehat.

Setelah Integration Hub dipasang berdampingan dengan SIMRS yang sudah ada, push FHIR berjalan otomatis per encounter klinis. DICOM Router native Kemenkes menerima output modality dan meneruskannya ke SatuSehat tanpa intervensi tim radiologi. Tim casemix tidak perlu lagi login dashboard SatuSehat untuk entri rutin; mereka hanya membuka ketika perlu memeriksa status push tertentu. Audit klaim juga lebih mudah karena setiap SEP terhubung ke encounter FHIR yang sama, sehingga reviewer internal bisa melacak kelengkapan dokumentasi sebelum klaim dikirim ke BPJS.

Pengalaman serupa terjadi di rumah sakit lain — bridging yang rapi memindahkan beban kerja klerikal kembali ke sistem, dan membebaskan tim klinis untuk pekerjaan yang sebenarnya. MedMinutes saat ini mendukung 50+ rumah sakit di 8+ provinsi.

Konteks Asosiasi: Suara PERSI

Tekanan klaim yang menggunung membuat asosiasi rumah sakit berbicara lebih keras dari biasanya. Pernyataan ini dikutip luas di media keuangan nasional.

"Bagi rumah sakit, bukan besar kecilnya pending klaim, tapi haknya diterima atau tidak."

— dr. Bambang Wibowo, Ketua Umum PERSI · Rapat Komisi IX DPR RI · 26 Mei 2025

Bisnis Indonesia

Konteks ini penting karena bridging bukan sekadar urusan teknis. Setiap klaim pending punya konsekuensi nyata: gaji dokter terlambat, pengadaan obat tertunda, arus kas rumah sakit terganggu. Bridging yang rapi mengurangi pending rate karena data klinis dan administrasi sudah konsisten sejak awal — verifikator BPJS lebih sedikit menemukan ketidakcocokan dokumen.

Frequently Asked Questions

Apa beda SatuSehat dan V-Claim BPJS?

SatuSehat adalah platform interoperabilitas data klinis yang dikelola Kemenkes dengan standar HL7 FHIR R4. V-Claim BPJS adalah ekosistem klaim BPJS Kesehatan yang memakai REST custom dengan enkripsi AES-256-CBC dan kompresi LZ-string. Keduanya menerima jenis data yang mirip (pasien, kunjungan, diagnosa) namun dengan format, otentikasi, dan tujuan berbeda. SatuSehat berfungsi sebagai data klinis nasional; V-Claim berfungsi sebagai mekanisme klaim asuransi sosial.

Apakah rumah sakit wajib bridging keduanya?

Bridging SatuSehat diatur oleh PMK 24/2022 Pasal 21 sebagai bagian dari kewajiban interoperabilitas RME. Kewajiban V-Claim mengikuti perjanjian kerja sama antara rumah sakit dan BPJS Kesehatan; setiap rumah sakit yang menerima pasien BPJS otomatis perlu integrasi V-Claim untuk SEP, klaim, dan rujukan. Kedua sistem berdiri di atas dasar hukum yang berbeda, namun praktiknya hampir semua rumah sakit di Indonesia menjalankan keduanya.

Berapa lama implementasi bridging?

Tergantung kondisi awal SIMRS atau RME yang sudah dipakai. Untuk rumah sakit yang sudah memakai RME modern dengan struktur data klinis yang rapi, bridging bisa dijalankan dalam beberapa minggu. Untuk rumah sakit dengan SIMRS legacy atau pencatatan masih hibrida (sebagian kertas), butuh fase pembersihan data dan pelatihan tim koding sebelum bridging stabil. Rentang umumnya antara satu sampai tiga bulan untuk go-live full coverage.

Bisakah pakai SIMRS open-source seperti Khanza?

Khanza dan SIMGOS (sistem milik pemerintah) menyediakan modul V-Claim dan integrasi SatuSehat. Beberapa rumah sakit pemerintah memakainya. Namun kebutuhan bridging tetap muncul saat rumah sakit ingin mengintegrasikan modul lain seperti DICOM Router, RME klinis pihak ketiga, atau dashboard analitik klaim. Bridging hub yang berdiri di samping SIMRS open-source membantu menjembatani modul-modul tersebut tanpa memodifikasi SIMRS inti.

Apa itu DICOM Router SatuSehat?

DICOM Router adalah aplikasi container Docker yang disediakan Kemenkes secara native untuk mengirim citra medis (CT, MRI, CR, dll) dari modality di rumah sakit ke SatuSehat. Router bertindak sebagai DIMSE listener di port 11112, menerima output C-STORE dari modality, lalu mengubah metadata menjadi resource ImagingStudy FHIR dan mengirimnya ke endpoint SatuSehat. Per pelaporan resmi, 30 rumah sakit sudah sukses pilot dan 10.619 fasyankes sudah aktif di Cluster Resource 6.

Bagaimana cara dapat consumer ID dan secret key BPJS?

Rumah sakit perlu mengajukan permohonan ke BPJS Kesehatan kantor cabang setempat, mengisi formulir pendaftaran developer, dan menandatangani perjanjian penggunaan API. Setelah disetujui, BPJS mengirimkan pasangan cons_id, cons_secret, dan user_key melalui email resmi. Kredensial ini wajib disimpan di sisi server dengan rotasi terjadwal dan tidak boleh ditanam langsung di kode SIMRS yang dipakai sehari-hari.

Bagaimana cara dapat client ID SatuSehat?

Client ID dan client secret SatuSehat diperoleh melalui pendaftaran fasyankes di portal SatuSehat Kemenkes. Setelah verifikasi data fasyankes (nomor registrasi, alamat, jenis layanan), Kemenkes menerbitkan kredensial untuk lingkungan staging dan produksi. Lingkungan staging memakai base URL api-satusehat-stg.dto.kemkes.go.id sementara produksi api-satusehat.kemkes.go.id. Tim IT wajib membaca dokumentasi resmi sebelum mengaktifkan kredensial produksi.

Apa konsekuensi tidak bridging?

Untuk SatuSehat, konsekuensi datang dari PMK 24/2022 Pasal 41 dengan sanksi administratif berjenjang dan implikasi pada akreditasi STARKES (bab MRMIK menempatkan interoperabilitas sebagai elemen penilaian). Untuk V-Claim, konsekuensi praktisnya adalah pengajuan klaim manual yang lambat, risiko pending klaim lebih tinggi, dan beban administratif besar bagi tim casemix. Jangka panjang, rumah sakit yang tidak bridging tertinggal dalam analitik dan benchmark layanan.

Apa beda V-Claim 1.1 dan 2.0?

V-Claim 2.0 memperkenalkan signature HMAC SHA-256 yang lebih kuat (versi sebelumnya memakai algoritma lama), perubahan struktur header, dan peningkatan kompresi LZ-string pada response. Beberapa endpoint juga ditambah seperti monitoring kunjungan dan rencana kontrol. Migrasi dari 1.1 ke 2.0 wajib bagi rumah sakit yang memakai library legacy.

Bagaimana transisi INA-CBG ke iDRG mempengaruhi bridging?

INA-CBG 5.9 berlaku per 1 April 2026 dan menjadi titik transisi menuju iDRG dengan 1.300+ groups dan lima level severity, dijadwalkan 2025 hingga 2027. Bridging hub harus mendukung dua skema tarif paralel selama masa transisi: format INA-CBG untuk klaim yang sudah dikirim dan dalam proses, format iDRG untuk klaim baru. Tanpa fleksibilitas ini, klaim bisa salah grouping dan tertahan di verifikator. BPJScan kami sudah mengaudit format ini dengan 78 filter klaim.

Apakah Integration Hub MedMinutes kompatibel dengan SIMRS yang sudah ada?

Ya. Integration Hub dirancang sebagai lapisan terjemahan yang berdiri di samping SIMRS atau RME yang sudah dipakai rumah sakit. Hub menerima data dari SIMRS lewat API atau pertukaran file, melakukan mapping ke FHIR R4 untuk SatuSehat dan ke format V-Claim untuk BPJS, lalu melakukan signing serta retry otomatis. Tim IT rumah sakit tidak perlu mengganti SIMRS-nya. MedMinutes adalah RME plus Integration Hub, bukan SIMRS billing-inventori-HR.

Berapa biaya implementasi?

Biaya implementasi tergantung jumlah resource yang dibridge, volume klaim bulanan, dan kondisi data awal. Rumah sakit kecil dengan volume rendah memerlukan setup yang lebih ringan; rumah sakit besar dengan banyak modality dan poliklinik memerlukan kapasitas lebih besar. Untuk gambaran biaya yang sesuai dengan kondisi rumah sakit, tim MedMinutes siap melakukan diskusi awal dan asesmen kebutuhan tanpa biaya melalui kontak yang tertera di akhir artikel ini.

Penutup

Bridging SatuSehat dan V-Claim BPJS adalah dua tugas teknis yang berdiri di atas regulasi berbeda, namun saling mengunci hasilnya. Tanpa bridging yang rapi, data klinis menjadi pulau yang terpisah dari data klaim, dan rumah sakit kehilangan kesempatan untuk audit cepat, pelaporan otomatis, dan arus kas yang sehat. Dengan bridging yang dirancang dengan benar — tiga lapis arsitektur, mapping yang taat standar, retry yang sabar — beban administratif tim casemix turun dan kepatuhan regulasi menjadi otomatis.

MedMinutes Integration Hub berdiri di samping SIMRS atau RME yang sudah dipakai rumah sakit. Kami menjembatani data ke SatuSehat dan V-Claim BPJS, dengan audit log dan retry queue yang membuat tim IT rumah sakit bisa tidur nyenyak. Saat ini kami mendukung 50+ rumah sakit di 8+ provinsi.

Diskusi awal Integration Hub MedMinutes lewat WhatsApp atau pelajari lebih lanjut di halaman Integration Hub.

Bridging SatuSehat dan V-Claim BPJS: Panduan Lengkap untuk Rumah Sakit Indonesia 2026