Optimizing INA-CBGs Bridging: A Complete Guide to Reducing Claim Rejections

Rejection of INA-CBGs claims is one of the biggest scourges for healthcare facilities (faskes) in Indonesia. Each rejection not only has the potential to cause significant financial losses but also burdens operational resources and reduces service efficiency. Internal data shows that faskes with suboptimal bridging systems can experience claim rejection rates of up to 15-20% of total submissions, which cumulatively can reach billions of rupiah per year. In the era of digitalization of health services and the continuously evolving BPJS Kesehatan ecosystem, having a reliable, efficient, and error-minimizing INA-CBGs bridging system is no longer an option but a necessity. This article will guide you, hospital IT managers, clinic owners, operational managers, and decision-makers, to deeply understand how INA-CBGs bridging works, technical implementation details, practical code examples, claim rejection handling strategies, and best practices to ensure your claims run smoothly and rejection rates can be minimized as much as possible.

Basic Concepts of INA-CBGs Bridging

INA-CBGs (Indonesia Case Base Groups) is a case-based healthcare payment system used in the National Health Insurance (JKN) by BPJS Kesehatan. In this system, each patient is grouped into diagnosis groups based on clinical characteristics and resources used, then paid with predetermined package rates. The concept of INA-CBGs bridging refers to the integration of a hospital management information system (SIMRS) or clinic information system with the BPJS Kesehatan platform, specifically VClaim and E-Klaim INA-CBGs, for automatic and real-time data exchange. The goal is to accelerate the claim submission process, minimize manual input errors, and improve data accuracy.

The bridging workflow begins when a patient registers at a healthcare facility. Patient data, primary diagnosis (based on ICD-10), secondary diagnoses, and medical procedures (based on ICD-9-CM) recorded in the SIMRS will be sent to the BPJS Kesehatan system. This process involves several crucial stages, such as creating a Participant Eligibility Letter (SEP) through VClaim, then sending complete medical record data to E-Klaim INA-CBGs for coding and verification. After the data is sent, the INA-CBGs system will group the case and generate a CBGs code that becomes the basis for calculating claim rates. The regulations underlying this system are very important to understand, such as Minister of Health Regulation (PMK) Number 59 of 2014 concerning Health Service Tariff Standards in the Implementation of the Health Insurance Program, as well as Presidential Regulation Number 82 of 2018 concerning Health Insurance, which serves as the main legal umbrella.

The data exchanged in the bridging process is very diverse and specific. This includes patient identity (NIK, BPJS number), medical data (diagnoses, procedures, discharge condition), administrative data (admission/discharge dates, treatment class), and other supporting data. The accuracy and completeness of this data are vital. For example, an error in writing the ICD-10 or ICD-9-CM code can directly cause claim rejection or an inappropriate change in the CBGs group, resulting in financial loss. Therefore, the bridging system must be able to perform initial validation of data before it is sent to BPJS Kesehatan, ensuring all established standards and formats are met.

Understanding these basic concepts is the foundation for building or optimizing an effective bridging system. Without a strong understanding of how data flows and is processed between SIMRS and the BPJS Kesehatan system, any effort to reduce claim rejections will be unfocused. Healthcare facilities that successfully implement bridging well usually experience an efficiency increase of up to 30% in the claim process and a significant reduction in rejection rates, often below 5%, compared to facilities that still rely on manual or semi-automatic processes.

Technical Implementation of INA-CBGs Bridging

Technically, the implementation of INA-CBGs bridging generally relies on an API (Application Programming Interface)-based architecture. BPJS Kesehatan provides a series of web services, both REST (Representational State Transfer)-based for the latest VClaim and SOAP (Simple Object Access Protocol) for some older services, which allow SIMRS to communicate programmatically. For VClaim 2.0 and beyond, BPJS Kesehatan has fully switched to the more modern and lightweight REST API, using JSON data format. Nevertheless, some healthcare facilities may still interact with SOAP services for legacy systems.

In modern SIMRS development, technologies commonly used to build bridging modules include PHP with frameworks such as Laravel version 10.x or 11.x, Node.js with Express.js, or Python with Django/Flask. The choice of these technologies is based on the existing ecosystem at the healthcare facility and the expertise of the development team. For example, Nugroho Setiawan's team often uses Laravel 11.x because of its rich ecosystem, good documentation, and ability to manage the complexity of API integration with Guzzle HTTP client version 7.x. For databases, PostgreSQL 16 or MySQL 8.x are popular choices due to their scalability and proven reliability in handling large volumes of medical record data.

Authenticating to the BPJS Kesehatan API is a crucial step. It involves using the Consumer ID, Secret Key, PPK ID (Provider Pelayanan Kesehatan ID), and User Key. The Consumer ID and Secret Key are used to obtain an access token, while the PPK ID and User Key identify the healthcare facility and the user making the request. This mechanism ensures that only registered and authorized healthcare facilities can access and submit data. It is important to manage these credentials securely, ideally stored as environment variables or in an encrypted secret management system, not directly in the source code.

The most frequently accessed API endpoints in bridging include creating a Participant Eligibility Letter (SEP), retrieving referral data, submitting claim data (diagnoses and procedures), and updating claim status. For example, to create a SEP, the SIMRS will send patient data, service type, and referral to the `/SEP/insert` endpoint. Every response from the BPJS Kesehatan API must be handled carefully, including the HTTP status code (e.g., 200 OK, 400 Bad Request, 500 Internal Server Error) and the error message returned. Robust logging implementation is essential to track every transaction and facilitate debugging when issues occur. Real-time monitoring of the bridging status is also recommended to quickly detect anomalies or data transmission failures. Although SatuSehat based on HL7 FHIR R4 is being rolled out, INA-CBGs bridging currently still predominantly uses the specific BPJS Kesehatan API, so an in-depth understanding of their standards is essential.

Integration Code Example

This section will present an example of PHP code that can be run to interact with the BPJS Kesehatan API, specifically to retrieve SEP data. This code is assumed to run in a PHP 8.2+ environment with the Laravel 10.x/11.x framework and uses the Guzzle HTTP client version 7.x. Make sure you have installed Guzzle via Composer: composer require guzzlehttp/guzzle.

First, we will define the BPJS Kesehatan API configuration in your .env file:

BPJS_CONS_ID="YOUR_CONS_ID"BPJS_SECRET_KEY="YOUR_SECRET_KEY"BPJS_USER_KEY="YOUR_USER_KEY"BPJS_BASE_URL="https://apijkn.bpjs-kesehatan.go.id/vclaim-rest/"

Next, we will create a service or repository class to manage interactions with the BPJS API. Here is an example function to obtain an access token and then retrieve SEP data:

<?phpnamespace App\'Services;use GuzzleHttp\Client;use GuzzleHttp\Exception\RequestException;class BpjsService{    protected $client;    protected $baseUrl;    protected $consId;    protected $secretKey;    protected $userKey;    public function __construct()    {        $this->baseUrl = env('BPJS_BASE_URL');        $this->consId = env('BPJS_CONS_ID');        $this->secretKey = env('BPJS_SECRET_KEY');        $this->userKey = env('BPJS_USER_KEY');        $this->client = new Client(['base_uri' => $this->baseUrl]);    }    protected function generateSignature()    {        $timestamp = strval(time() * 1000); // Time in milliseconds        $signature = hash_hmac('sha256', $this->consId . '&' . $timestamp, $this->secretKey);        return [            'timestamp' => $timestamp,            'signature' => $signature        ];    }    public function getSepData(string $noSep)    {        try {            $signatureData = $this->generateSignature();            $headers = [                'X-cons-id' => $this->consId,                'X-timestamp' => $signatureData['timestamp'],                'X-signature' => $signatureData['signature'],                'user_key' => $this->userKey,                'Content-Type' => 'application/json'            ];            $response = $this->client->request('GET', "SEP/$noSep", [                'headers' => $headers            ]);            $body = json_decode($response->getBody()->getContents(), true);            if ($body['metaData']['code'] == 200) {                return $body['response'];            } else {                throw new \Exception($body['metaData']['message']);            }        } catch (RequestException $e) {            $responseBody = $e->getResponse() ? $e->getResponse()->getBody()->getContents() : 'No response body';            throw new \Exception("BPJS API Error: " . $responseBody . " - " . $e->getMessage());        } catch (\Exception $e) {            throw new \Exception("General Error: " . $e->getMessage());        }    }}

Explanation of the code above: The BpjsService class initializes the Guzzle HTTP client with the BPJS API base URL. The generateSignature() function creates the X-timestamp and X-signature authentication headers required by the BPJS API. The timestamp is calculated in milliseconds and the signature is created using HMAC SHA256 with the Consumer ID, timestamp, and Secret Key. The getSepData(string $noSep) function then uses these authentication headers to make a GET request to the /SEP/{noSep} endpoint. If the response has code 200, the SEP data is returned; otherwise, or if a network error occurs, an exception is thrown. This implementation ensures that every request to the BPJS API is properly authenticated and errors are handled in a structured manner. This is an important foundation for a stable and reliable bridging module, reducing the risk of claim rejections due to technical authentication issues or incorrect request formats.

Handling Claim Rejections: Case Study

Claim rejection can occur for various reasons, ranging from data input errors, coding discrepancies, to administrative issues. Understanding the common causes and how to handle them is key to increasing the percentage of successful claims. Let's take a case study of claim rejection with a realistic example payload and error message.

For example, you submit a JSON payload for claim creation (simulation of data to be sent to the INA-CBGs E-Klaim system after SEP is created) as follows:

{  "metadata": {    "method": "insert",    "nomor_sep": "0189R00109230000001",    "kode_faskes": "0189R001"  },  "data": {    "nomor_rm": "RM0012345",    "tgl_masuk": "2023-09-01 10:00:00",    "tgl_keluar": "2023-09-05 14:30:00",    "diagnosa_utama": "I10",    "diagnosa_sekunder": ["E11.9", "N18.9"],    "prosedur": ["88.72", "39.95"],    "berat_lahir": null,    "cara_pulang": "1",    "jenis_rawat": "1",    "kelas_rawat": "2",    "tarif_rs": {      "prosedur_non_bedah": 1500000,      "prosedur_bedah": 3000000,      "konsultasi": 500000,      "bhp": 750000,      "obat": 1200000,      "alkes": 800000,      "lain_lain": 400000    },    "user": "dokter_andi"  }}

However, you receive an error message from the BPJS Kesehatan system, for example:

{  "metaData": {    "code": "400",    "message": "Diagnosa utama (I10) tidak sesuai dengan prosedur yang diklaim (88.72)."  }}

Analysis of the cause of this rejection indicates a discrepancy between the primary diagnosis code (I10 - Essential Hypertension) and the recorded procedure code (88.72 - Abdominal Ultrasonography). The INA-CBGs system has strong validation logic to ensure consistency between diagnoses and medical actions. In this case, it is highly unusual for a patient with a primary diagnosis of essential hypertension to undergo abdominal ultrasonography as the primary procedure directly related to that diagnosis without a supporting secondary diagnosis or clear clinical reason. Similar rejections can also occur if the procedure code is invalid, the SEP is not found, or administrative data is not synchronized.

Handling strategies for this case include: First, **strict pre-claim data validation** in the SIMRS. Before submitting the payload, the system must check the consistency of ICD-10 and ICD-9-CM. For example, using a coding rules database or a simple algorithm to detect anomalies. Second, **periodic data reconciliation** between SIMRS and manual medical records. Ensure that medical coders and doctors have the same understanding of coding standards. In this case, there may be a coding error in SIMRS, or the doctor forgot to record a relevant secondary diagnosis (for example, 'Abdominal Pain' - R10) that supports the abdominal ultrasound procedure. Third, **proactive communication with BPJS verifiers**. If after re-validating the data it is believed to be correct, the healthcare facility can contact the BPJS Kesehatan verifier for clarification and resubmission with additional explanation. Rejections can often be avoided by ensuring data accuracy at the source, namely during input in the medical record and the coding process. Implementing intelligent automatic validation in SIMRS can reduce rejections due to data inconsistency by up to 70%.

Best Practices

1. Strict Pre-Claim Data Validation: Implement validation logic in your SIMRS to check the completeness and consistency of data (ICD-10, ICD-9-CM, demographic data) before sending it to the BPJS API. This can include format validation, value ranges, and even simple coding rules to prevent early rejections.
2. Regular Master Data Synchronization: Ensure that master data such as the list of doctors, service units, and procedure codes in SIMRS are always in sync with the data registered in BPJS Kesehatan. Schedule an automatic daily or weekly synchronization process to minimize data discrepancies that could trigger rejections.
3. Implementation of Robust Logging & Monitoring: Every transaction to the BPJS API must be logged in detail, including request payload, response, timestamp, and HTTP status. Use a real-time monitoring system to detect API failures or data transmission anomalies as soon as possible.
4. Continuous Training for Coders & Medical Staff: Coding errors are a major cause of claim rejections. Conduct regular training for medical coders and clinical staff on ICD-10, ICD-9-CM coding standards, as well as the latest BPJS Kesehatan guidelines, at least twice a year.
5. Regular System Updates: The BPJS Kesehatan API and INA-CBGs standards can change. Ensure that your bridging system is always updated to accommodate API changes, standard versions, or the latest regulations. Subscribe to official notifications from BPJS Kesehatan and perform regression testing after every update.
6. Efficient Use of Cache: For data that rarely changes, such as the list of polyclinics or referral data that is valid for a certain period, use a caching mechanism in your SIMRS. This will reduce the load on the BPJS API and speed up your system's response, although there still needs to be a periodic refresh mechanism.
7. Proactive Communication with BPJS Kesehatan: Build good relationships with the verifier and technical teams of BPJS Kesehatan in your area. Do not hesitate to discuss or request clarification if there are unusual rejection patterns or technical difficulties you are experiencing.
8. Implementation of Automatic Retry Mechanism: For temporary failures (for example, the BPJS server is busy), implement a retry mechanism with an exponential back-off strategy. This will automatically try to resend the data after some time, reducing the need for manual intervention.
9. Maximum Data Security: Ensure that all sensitive patient data sent through the bridging is encrypted (HTTPS/TLS 1.2+). Manage API credentials (Consumer ID, Secret Key, User Key) very securely, ideally in a secret management system or encrypted environment variables, not hardcoded in the code.

FAQ

1. What is the main difference between INA-CBGs bridging and SatuSehat?

INA-CBGs bridging focuses on data exchange for the BPJS Kesehatan claim process, especially diagnoses and procedures, so that they can be grouped into CBGs and paid for. Meanwhile, SatuSehat is a national health interoperability platform based on the FHIR R4 standard that aims to integrate all patient medical record data from various healthcare facilities. Although both involve the exchange of health data, INA-CBGs bridging is more specific to claim needs, while SatuSehat is broader for integrated electronic medical records.

2. How do healthcare facilities obtain a Consumer ID and Secret Key for the BPJS API?

Consumer ID and Secret Key can be obtained through the local BPJS Kesehatan branch office or through the BPJS Kesehatan technical team. Healthcare facilities need to submit an official application and will usually go through a verification process. These credentials are confidential and must be kept secure because they provide access to the BPJS Kesehatan system for submitting claim data.

3. How often does the BPJS Kesehatan API change and how do healthcare facilities find out?

The BPJS Kesehatan API, especially VClaim, undergoes regular updates, although major changes are rare. Minor changes or feature additions can occur several times a year. Healthcare facilities can monitor official announcements from BPJS Kesehatan through the portal or communication groups provided. It is highly recommended to join the BPJS developer forum or mailing list to get the latest information directly.

4. What are the main causes of INA-CBGs claim rejections that occur most frequently?

The main causes of claim rejections include mismatches between diagnoses and procedures (incorrect coding), incomplete or incorrect administrative data (for example, an invalid SEP number), differences in data between SIMRS and the BPJS Kesehatan system (for example, admission/discharge dates), as well as patient conditions that do not meet eligibility criteria. Technical errors in sending data through the API can also be a trigger, although they are rarer if the bridging system is stable.

5. Are there any recommended third-party tools to help with INA-CBGs bridging?

Several SIMRS vendors offer integrated bridging modules that have been tested. In addition, there are also middleware or API Gateway services that can help manage the connection and data transformation between your SIMRS and the BPJS Kesehatan API. It is important to choose a tool or vendor that has a good track record, responsive technical support, and has been proven to comply with BPJS Kesehatan standards. The Nugroho Setiawan team also provides custom solutions for this integration.

6. How can patient data security be ensured when performing INA-CBGs bridging?

To ensure the security of patient data, healthcare facilities must implement multiple layers of protection. First, ensure all communications use the HTTPS protocol (TLS 1.2 or higher) to encrypt data during transmission. Second, manage API credentials securely, avoid hardcoding them in the code. Third, implement strict access controls on your SIMRS, granting access to the bridging module only to authorized staff. Fourth, conduct regular security audits on your system. Finally, comply with personal data protection regulations as stipulated in the PDP Law in Indonesia.

Building a solid and effective INA-CBGs bridging system is a crucial investment for every healthcare facility that wants to optimize operations and finances in the JKN era. By understanding the basic concepts, implementing best technical practices, and proactively addressing potential claim rejections, you can significantly improve the efficiency of the claims process and reduce losses. Do not let the complexity of integration become a barrier to better and sustainable healthcare services. If your healthcare facility faces similar challenges or needs in-depth consultation to optimize SIMRS and bridging integration in accordance with the latest standards, our team is ready to help. Contact Nugroho Setiawan for further discussion and appropriate technology solutions, ensuring your system runs optimally and your claims are accepted without significant obstacles.

Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): SIMRS (Hospital Information System) BPJS & SatuSehat Integration. Need a free consultation?