Optimizing INA-CBG Bridging: The Key to Reducing BPJS Kesehatan Claim Rejections

The high rate of INA-CBG claim rejections by BPJS Kesehatan often becomes a scourge for healthcare facilities (faskes). Data shows that in some hospitals, claim rejection rates can reach 15% to 20%, resulting in significant financial losses, slowed cash flow, and unnecessary administrative burdens. This is not only a financial problem, but also a reflection of inefficiency in the hospital information management system (SIMRS) and the claim submission process. In the context of the national health insurance system (JKN), which adopts INA-CBG-based prospective payment, the ability of faskes to manage data and submit claims accurately and on time is crucial. INA-CBG bridging is the backbone of this process, bridging patient medical data with the BPJS Kesehatan verification system. However, many faskes still struggle with its technical and administrative complexity. This article will thoroughly examine how the INA-CBG bridging system works, the technical architecture involved, implementation details with code examples, payload analysis and effective error handling, as well as actionable best practices to significantly reduce claim rejections, ensuring operational efficiency and optimizing your faskes revenue.

Understanding INA-CBG Bridging Architecture: From Medical Records to Claim Verification

INA-CBG (Indonesia Case Based Groups) is a prospective payment system used by BPJS Kesehatan, in which healthcare service tariffs are determined based on grouping patient diagnoses and medical procedures. This system aims to improve efficiency and transparency in health financing. Essentially, each patient case will be grouped into a specific INA-CBG group that has a standard tariff. This process starts from patient medical record data, which includes the primary diagnosis, secondary diagnoses, and the actions or procedures performed.

The role of bridging in the context of INA-CBG is vital. Bridging is a service or middleware that functions as a data bridge between the SIMRS (Hospital Management Information System) used by faskes and the VClaim/E-Klaim application owned by BPJS Kesehatan. Without effective bridging, the claim submission process becomes manual, slow, and highly prone to errors. The data flow broadly begins when a patient registers and receives services. All service data, from history taking, physical examination, laboratory results, to medication administration and procedures, will be recorded in the SIMRS. After services are completed, the doctor or medical coder will perform diagnosis coding using ICD-10 standards and procedure coding using ICD-9-CM. This coding data is then processed by the bridging system.

The bridging system will retrieve coding data and other relevant patient information from the SIMRS, then format it according to the standards set by the BPJS Kesehatan API, and send it to the VClaim or E-Klaim application. On the BPJS side, the data will go through the INA-CBG grouping process to determine the tariff, and then be verified. If the data is complete and accurate, the claim will be approved; if not, the claim will be rejected or requested to be completed. The main components in this architecture include SIMRS as the primary data source, Bridging Service or middleware as the connector, BPJS Kesehatan API (VClaim for SEP and patient data, E-Klaim for INA-CBG claim submission), and the faskes internal database for storing transaction logs and claim status. The legal basis underlying INA-CBG implementation is Minister of Health Regulation (PMK) No. 59 of 2014 and its amendments, which regulate healthcare service tariff standards in the JKN program.

As a concrete example, when a patient is diagnosed with Dengue Hemorrhagic Fever (DHF) with ICD-10 code A90, and receives an intravenous infusion procedure (for example ICD-9-CM code 99.21), the bridging system will collect this information along with patient demographic data, SEP number, and service date from the SIMRS. This data is then sent to BPJS for grouping and verification. The technology commonly used to build this bridging service is web service, both SOAP and REST, with XML or JSON data formats. It is important to ensure that all transmitted data conforms to the structure and validation expected by the BPJS Kesehatan API to avoid claim rejection from the outset.

Technical Implementation Details of Bridging: From API to Database Integration

The technical implementation of INA-CBG bridging requires a deep understanding of system architecture and cross-platform integration. Essentially, faskes need to build or adopt a middleware layer capable of two-way communication between the SIMRS and the BPJS Kesehatan API. This middleware layer acts as a translator and data sender. For SIMRS, many faskes use custom systems, or commercial solutions such as Mediface, or even modified open-source systems such as OpenMRS. Whatever SIMRS is used, the key is the ability to export relevant medical data in a structured manner.

This bridging layer or middleware is usually built using the latest web development technologies. For example, many developers choose Node.js (e.g., Node 20 LTS version) with the Express.js or NestJS framework to build an efficient and scalable bridging API. Another alternative is PHP (e.g., with the Laravel 11.x framework) or Java (with Spring Boot). The choice of technology depends on the preferences of the healthcare facility's IT team and the existing technology ecosystem. This middleware should also ideally connect to a separate database, such as PostgreSQL 16 or MySQL 8, to store logs of data submission transactions, the status of each claim (sent, successful, failed, rejected), and any necessary mapping data, such as mapping local diagnosis codes to ICD-10 or mapping local procedure codes to ICD-9-CM.

The process of submitting data through bridging begins with the creation of a Participant Eligibility Letter (SEP) through the VClaim API. Patient and referral data from the SIMRS are sent to VClaim to obtain the SEP number, which becomes the primary identification for the service. After the service is completed and coding is performed, the validated coding data will be sent to the E-Klaim API. The payload sent to this E-Klaim API is much more complex, including primary and secondary diagnosis data, medical procedures, admission and discharge dates, type of care, class of care, and cost details. After the claim data is received by BPJS, the INA-CBG grouping process will run on their side, followed by verification by a BPJS verifier. The result of this verification determines whether the claim is approved or rejected.

The importance of data standardization cannot be ignored. Although the BPJS Kesehatan API is currently still REST/SOAP-based with specific payloads, an understanding of healthcare interoperability standards such as FHIR R4 or HL7 v2.5.1 is highly relevant. This is because the SatuSehat initiative from the Ministry of Health will adopt the FHIR standard, which means that in the future, SIMRS will be expected to be able to communicate using this standard. By implementing a flexible and standards-oriented bridging system, healthcare facilities can prepare themselves for the transition to a more integrated SatuSehat ecosystem. Choosing stable tools and versions such as Laravel 11.x for the backend, Node.js 20 LTS for the runtime, and PostgreSQL 16 for the database will provide a strong foundation for a reliable and easy-to-maintain bridging system.

Code Case Study: Automation of SEP Data and Claim Submission

To provide a concrete illustration, the following is a simple implementation example using PHP with the Laravel HTTP Client (which utilizes Guzzle) to interact with the BPJS Kesehatan API. This code shows how SEP data and INA-CBG claims can be sent automatically from your bridging system. Keep in mind that this is a basic example, and in a real implementation there will be more comprehensive validation, error handling, and logging.

Code Example 1: Sending SEP Data to VClaim API

This code shows a function to generate the signature required by the BPJS Kesehatan API and then uses the Laravel HTTP Client to send the SEP creation request. Make sure you replace placeholders such as YOUR_CONS_ID and YOUR_SECRET_KEY with your actual API credentials.

use Illuminate\Support\Facades\Http;use Carbon\Carbon;function generateSignature($consId, $secretKey) {
    $timestamp = Carbon::now()->timestamp * 1000; // Epoch time in milliseconds
    $stringToSign = $consId . '&' . $timestamp . '&' . $secretKey;
    $signature = base64_encode(hash_hmac('sha256', $stringToSign, $secretKey, true));
    return ['timestamp' => $timestamp, 'signature' => $signature];
}$consId = 'YOUR_CONS_ID'; // Ganti dengan Cons ID Anda
$secretKey = 'YOUR_SECRET_KEY'; // Ganti dengan Secret Key Anda
$baseUrlVClaim = 'https://apijkn-dev.bpjs-kesehatan.go.id/vclaim-kemenkes-dev/'; // Ganti dengan base URL VClaim yang sesuai
$auth = generateSignature($consId, $secretKey);
$sepData = [
    'request' => [
        't_sep' => [
            'noKartu' => '0001234567890',
            'tglSep' => '2023-10-26',
            'ppkPelayanan' => '0301R001', // Kode PPK Pelayanan
            'jnsPelayanan' => '2', // 1=Ranap, 2=Rajal
            'klsRawat' => [
                'klsRawatHak' => '3', // Kelas rawat hak
                'klsRawatNaik' => '',
                'pembiayaan' => '',
                'penanggungJawab' => ''
            ],
            'noMR' => 'MR00123',
            'rujukan' => [
                'asalRujukan' => '1', // 1=Faskes 1, 2=Faskes 2
                'tglRujukan' => '2023-10-25',
                'noRujukan' => 'RJK001',
                'ppkRujukan' => '0301R001'
            ],
            'catatan' => 'Suspek DBD',
            'diagAwal' => 'A90', // Kode ICD-10 Diagnosis Awal
            'poli' => [
                'tujuan' => 'INT', // Kode Poli Tujuan
                'eksekutif' => '0'
            ],
            'cob' => [
                'cob' => '0'
            ],
            'katarak' => [
                'katarak' => '0'
            ],
            'jaminan' => [
                'lakaLantas' => '0',
                'noLp' => '',
                'tglKejadian' => '',
                'keterangan' => '',
                'suplesi' => [
                    'suplesi' => '0',
                    'noSepSuplesi' => '',
                    'lokasiLaka' => [
                        'kdPropinsi' => '',
                        'kdKabupaten' => '',
                        'kdKecamatan' => ''
                    ]
                ]
            ],
            'tujuanKunj' => '0', // 0=Normal, 1=Prosedur, 2=Konsul
            'flagProcedure' => '',
            'kdPenunjang' => '',
            'assesmentPel' => '',
            'sumberData' => '',
            'tglKunjungan' => '',
            'dpjpLayan' => '99999', // Kode DPJP
            'noTelp' => '081234567890',
            'penjamin' => '',
            'user' => 'Nugroho Setiawan'
        ]
    ]];try {
    $response = Http::withHeaders([
        'X-cons-id' => $consId,
        'X-timestamp' => $auth['timestamp'],
        'X-signature' => $auth['signature'],
        'Content-Type' => 'application/json',
        'Accept' => 'application/json'
    ])->post($baseUrlVClaim . 'SEP/2.0/insert', $sepData);
    $result = $response->json();
    if ($response->successful() && $result['metaData']['code'] == '200') {
        echo 'SEP berhasil dibuat: ' . $result['response']['sep']['noSep'];
    } else {
        echo 'Gagal membuat SEP: ' . $result['metaData']['message'];
    }
} catch (\Exception $e) {
    echo 'Terjadi kesalahan: ' . $e->getMessage();
}}

Example Code 2: Sending INA-CBG Claim Data to E-Klaim API

After the SEP is successfully created, the next step is to send complete claim data to the E-Klaim API. This payload contains medical and administrative details that will be used by BPJS for the grouping and verification process. Note the claimData data structure, which includes many key parameters that affect the claim process.

use Illuminate\Support\Facades\Http;use Carbon\Carbon;function generateSignature($consId, $secretKey) {    $timestamp = Carbon::now()->timestamp * 1000;    $stringToSign = $consId . '&' . $timestamp . '&' . $secretKey;    $signature = base64_encode(hash_hmac('sha256', $stringToSign, $secretKey, true));    return ['timestamp' => $timestamp, 'signature' => $signature];}$consId = 'YOUR_CONS_ID';$secretKey = 'YOUR_SECRET_KEY';$baseUrlEKlaim = 'https://apijkn-dev.bpjs-kesehatan.go.id/eklaim-kemenkes-dev/'; // Ganti dengan base URL E-Klaim yang sesuai$auth = generateSignature($consId, $secretKey);$claimData = [    'metadata' => [        'method' => 'new_claim', // Atau 'update_claim'        'nomor_kartu' => '0001234567890',        'no_sep' => '0301R00110230000001', // Nomor SEP yang sudah dibuat        'nomor_rm' => 'MR00123',        'tgl_masuk' => '2023-10-26 08:00:00',        'tgl_pulang' => '2023-10-28 17:00:00',        'jenis_rawat' => '2', // 1=Ranap, 2=Rajal        'kelas_rawat' => '3', // Kelas rawat pasien        'rujukan' => '1', // 1=Faskes 1, 2=Faskes 2        'poli_perujuk' => '001', // Kode poli perujuk        'diagnosa' => 'A90,R50.9', // ICD-10 primer, sekunder dipisahkan koma        'procedure' => '89.01,99.21', // ICD-9-CM prosedur, dipisahkan koma        'tarif_rs' => '5000000', // Total tarif RS        'tarif_poli_eks' => '0',        'adl_sub_acute' => '0',        'adl_chronic' => '0',        'icu_indikator' => '0', // 0=Tidak, 1=Ya        'icu_los' => '0', // Lama hari di ICU        'ventilator_indikator' => '0',        'ventilator_los' => '0',        'upgrade_kelas_pct' => '0',        'upgrade_kelas_nilai' => '0',        'upgrade_kelas_los' => '0',        'lab_darah' => '1', // 0=Tidak, 1=Ya        'radiologi' => '1',        'rehab_medik' => '0',        'lain_lain' => '0',        'obat_kronis_total' => '0',        'obat_kemoterapi' => '0',        'perawat_spesialis' => '0',        'katarak_indikator' => '0',        'bayi_baru_lahir' => '0',        'bayi_berat_lahir' => '0',        'co_insidense' => '0',        'sistole' => '0',        'diastole' => '0',        'berat_badan' => '0',        'tinggi_badan' => '0',        'respirasi' => '0',        'heart_rate' => '0',        'tgl_lahir' => '1990-01-01',        'gender' => '1', // 1=Pria, 2=Wanita        'user' => 'Nugroho Setiawan'    ]];try {    $response = Http::withHeaders([        'X-cons-id' => $consId,        'X-timestamp' => $auth['timestamp'],        'X-signature' => $auth['signature'],        'Content-Type' => 'application/json',        'Accept' => 'application/json'    ])->post($baseUrlEKlaim . 'klaim/new', $claimData); // Endpoint bisa berbeda, cek dokumentasi    $result = $response->json();    if ($response->successful() && $result['metadata']['code'] == '200') {        echo 'Klaim berhasil diajukan: ' . $result['metadata']['message'];    } else {        echo 'Gagal mengajukan klaim: ' . $result['metadata']['message'];    }} catch (\Exception $e) {    echo 'Terjadi kesalahan: ' . $e->getMessage();}}

These two code examples illustrate basic interaction with the BPJS Kesehatan API. It is important to implement robust error handling mechanisms, detailed transaction logging, and data validation on the SIMRS side before submission. Every API transaction must be recorded, including the request payload, BPJS response, and final status, to facilitate debugging and auditing processes in the future. Collaboration between the IT team, coders, and doctors is very important to ensure that the data sent is accurate and in accordance with the patient's medical records.

Analyzing Payload and Error Handling for INA-CBG Claims

Understanding the structure of the payload sent to the BPJS Kesehatan E-Klaim API is key to reducing rejections. The payload is a data package containing all the information needed by BPJS to process your claim. Every element in the payload must be accurate and comply with standards. The following is a realistic JSON payload example for submitting an INA-CBG claim:

The following is a realistic JSON payload example for submitting an INA-CBG claim:

{
  "metadata": {
    "method": "new_claim"
  },
  "data": {
    "nomor_sep": "0301R0110126V000123",
    "nomor_kartu": "0001234567890",
    "tgl_masuk": "2026-01-10 08:30:00",
    "tgl_pulang": "2026-01-13 14:00:00",
    "jenis_rawat": "1",
    "kelas_rawat": "3",
    "diagnosa_utama": "A91",
    "diagnosa_sekunder": ["E11", "I10"],
    "prosedur": ["99.15"],
    "ina_cbg": "A-4-10-I",
    "tarif_rs": 4500000,
    "tarif_ina_cbg": 4200000,
    "los": 3,  }}

Note that every field has strict data types and formats. Small errors such as date format, invalid ICD codes, or discrepancies between diagnosis and procedure can cause claims to be rejected. Therefore, layered validation on the SIMRS side is highly recommended before data is sent to BPJS.

Practical Tips for Reducing INA-CBG Claim Rejections

1. Perform double validation before submission. Apply layered validation rules: format validation (date, ICD code, SEP number), logic validation (suitability of diagnosis with procedure, LOS with type of care), and business validation (tariff according to class, completeness of documents). Use validation libraries such as Laravel Validation or JSON Schema to ensure the payload meets BPJS standards. Save validation logs so the coder team can trace the source of errors quickly.

2. Build a retry and queue mechanism. The BPJS network or server may experience temporary disruptions. Implement a retry mechanism with exponential backoff for non-fatal failures, as well as a queue (queue) for mass submissions. Separate claim statuses into draft, pending, sent, and rejected so that monitoring is more structured. That way, failed claims do not simply disappear and can be resent automatically.

3. Involve the coder and verifier teams from the start. Claim rejections often stem from mismatches between the medical summary and the entered data. Hold regular reviews between the IT team, coders, and doctors to align perceptions. Create a verification checklist before claims are submitted, for example ensuring the primary diagnosis matches, procedures are fully recorded, and there is no claim duplication. With this collaboration, the rejection rate can be significantly reduced.

FAQ

What are the most common causes of INA-CBG claims being rejected?

The most common causes are mismatches between diagnosis codes and procedures, incomplete patient data, claim duplication, and format errors in the API payload. Layered validation and coordination with the coder team greatly help reduce these risks.

Is INA-CBG bridging required to use the E-Klaim API?

Not always. Bridging can be done through the E-Klaim API, the E-Klaim desktop application, or direct integration with SIMRS. However, the E-Klaim API offers better automation and speed, especially for hospitals with high claim volumes.

How should claims that fail to send due to server disruptions be handled?

Store the payload in a local queue, record the failure status, and perform retries periodically. Ensure every attempt is logged for audit. If the disruption continues, coordinate with the local BPJS team.

Can INA-CBG rates differ from hospital rates?

Yes. INA-CBG rates are set based on diagnosis groups and care class, so they can be lower or higher than the hospital's actual rates. This difference needs to be managed well, for example through cost efficiency or adjustments to service patterns.

Optimizing INA-CBG bridging is not merely a technical matter, but a combination of a reliable system, a strict validation process, and cross-team collaboration. By applying the tips above, hospitals can reduce claim rejection rates, accelerate disbursement, and maintain the sustainability of healthcare services. Do not hesitate to consult our INA-CBG bridging expert team to audit your system, identify rejection gaps, and design targeted solutions. Contact us now and ensure your BPJS Kesehatan claims are processed without obstacles.

This article is part of the education by Nugroho Setiawan, an IT consultant in Jogja. Related solutions: SIMRS Integrator Bridging BPJS & SatuSehat. Need a free consultation?