Exploring INA-CBGs Bridging: An IT Solution for Efficient BPJS Claims

Amid the dynamics of the national health system, managing BPJS Kesehatan claims is often one of the crucial points that directly impacts the financial stability and operational efficiency of hospitals and clinics. In fact, many healthcare facilities are still grappling with high rates of INA-CBGs claim rejections, which are often caused by data inaccuracies, error-prone manual processes, or non-compliance with the latest regulatory standards. This situation not only hampers cash flow but also consumes the time and resources of administrative teams that should be allocated to patient care. Understanding this complexity, the need for a robust and integrated INA-CBGs bridging system becomes very urgent. This article will take you deeper into the working mechanisms of INA-CBGs bridging, outline the required technical architecture, and present concrete tips and strategies based on technology implementation to significantly reduce claim rejection rates. We will include code examples, error handling scenarios, and best practices that you can directly apply.

Basic Concepts of INA-CBGs Bridging and Data Process Flow

INA-CBGs (Indonesia Case Based Groups) is a prospective payment system used by BPJS Kesehatan, in which healthcare service tariffs are determined based on the grouping of diagnoses and medical procedures. This system aims to improve the efficiency and transparency of service costs. INA-CBGs bridging, in the context of information technology, is an integration mechanism between the Hospital Management Information System (SIMRS) or Clinic Management Information System (SIM Klinik) and the BPJS Kesehatan system, including VClaim (Claim Verification) and E-Klaim INA-CBGs. Its main purpose is to automate claim data submission, data validation, and accelerate the verification process.

The bridging data process flow begins when a patient registers at a healthcare facility. Patient data and registration information will be input into SIMRS. After medical services are completed, the diagnosis data (using ICD-10) and procedures (using ICD-9-CM) provided by the doctor will be accurately recorded in SIMRS. From here, the bridging system will play a vital role. First, registration data and patient identity will be sent to the BPJS VClaim system for the creation of a Participant Eligibility Letter (SEP). This data includes the BPJS card number, referral data, and basic patient information. After the SEP is successfully issued, the process continues with the submission of detailed medical data to the E-Klaim INA-CBGs system.

The data payload sent to E-Klaim includes detailed information such as the primary diagnosis, secondary diagnosis, medical procedures, service date, and other supporting data. The E-Klaim system will then perform a grouping process based on the INA-CBGs algorithm to determine the tariff category. After grouping, the data will be verified by the BPJS verifier. Data discrepancies at any of these stages, from registration to medical data submission, are the main cause of claim rejections. Therefore, high data integrity, strict validation on the SIMRS side, and real-time synchronization between internal and external systems are the keys to successful INA-CBGs bridging implementation. All data must comply with the standards of PMK No. 59 of 2014 and PMK No. 76 of 2016 governing INA-CBGs.

Technical Architecture and Efficient Bridging Implementation

An efficient INA-CBGs bridging implementation requires a solid technical architecture and the right choice of technology. Basically, communication between SIMRS/SIM Klinik and the BPJS Kesehatan system (VClaim and E-Klaim) is done through RESTful API. This means your system will send HTTP requests (POST, GET) with data payloads in JSON format to the BPJS API endpoint and receive responses also in JSON format.

For the backend, common and proven effective technology choices include PHP with the Laravel framework (version 11.x and above) or Node.js with the Express.js framework (using Node 20 LTS). Laravel offers a rich ecosystem for API development, including the Eloquent ORM that facilitates database interaction and the Guzzle HTTP Client for external API requests. Meanwhile, Node.js excels in non-blocking I/O performance that is suitable for applications that interact heavily with external APIs, using Axios or Node-fetch as the HTTP client.

Relational databases such as PostgreSQL 16 or MySQL 8.x are highly recommended for storing SIMRS data and bridging transaction logs. PostgreSQL, in particular, is known for its strong data integrity and good scalability to handle large volumes of medical data. In terms of API communication, it is important to ensure the use of SSL/TLS (HTTPS) for encryption of transmitted data, as well as implementing authentication using the API Key and Secret provided by BPJS Kesehatan. Every request must include a valid authentication header.

The data standards used must strictly refer to applicable regulations, such as PMK No. 59 of 2014, PMK No. 76 of 2016, and PMK No. 51 of 2018 regarding INA-CBGs. For future interoperability, also consider using the FHIR R4 (Fast Healthcare Interoperability Resources) standard, which forms the basis of the SatuSehat initiative, although currently BPJS still uses their specific JSON API format. A good implementation should also include a comprehensive logging system to record every API request and response, as well as real-time monitoring to detect anomalies or data transmission failures as quickly as possible.

Example Code for Bridging API Implementation

The following is an example of a simple implementation using PHP (Laravel 11.x) and the Guzzle HTTP Client to interact with the BPJS VClaim and E-Klaim APIs. This code will show the basic structure for sending data.

Code 1: Sending SEP (Participant Eligibility Letter) Data to BPJS VClaim

This code shows how to make a POST request to the VClaim API to create a SEP. Make sure you have installed the Guzzle HTTP Client (composer require guzzlehttp/guzzle) and configured the API Key/Secret in your Laravel .env file.

<?phpnamespace App\pjs;use GuzzleHttp\Client;use GuzzleHttp\Exception\RequestException;class VclaimService{    protected $client;    protected $baseUrl;    protected $consId;    protected $secretKey;    protected $userKey;    public function __construct()    {        $this->consId = env('BPJS_CONS_ID');        $this->secretKey = env('BPJS_SECRET_KEY');        $this->userKey = env('BPJS_USER_KEY_VC');        $this->baseUrl = env('BPJS_VCLAIM_BASE_URL');        $this->client = new Client([            'base_uri' => $this->baseUrl,            'timeout'  => 10.0,        ]);    }    public function createSep(array $data)    {        try {            $timestamp = time();            $signature = $this->generateSignature($timestamp);            $headers = [                'X-cons-id' => $this->consId,                'X-timestamp' => $timestamp,                'X-signature' => $signature,                'user_key' => $this->userKey,                'Content-Type' => 'Application/json'            ];            $response = $this->client->post('/SEP/2.0/insert', [                'headers' => $headers,                'json' => ['request' => ['t_sep' => $data]]            ]);            return json_decode($response->getBody()->getContents(), true);        } catch (RequestException $e) {            return ['error' => $e->getMessage(), 'response' => $e->getResponse() ? json_decode($e->getResponse()->getBody()->getContents(), true) : null];        }    }    protected function generateSignature($timestamp)    {        $data = $this->consId . '&' . $timestamp;        $hash = hash_hmac('sha256', $data, $this->secretKey, true);        return base64_encode($hash);    }}

Explanation of Code 1: The VclaimService class initializes the Guzzle Client with the base URL and timeout. The createSep method accepts a $data array containing the SEP payload. Before sending, it creates the timestamp and signature required for authentication. The signature is calculated using hash_hmac with SHA256 and Base64-encoded. The request headers are filled with X-cons-id, X-timestamp, X-signature, and user_key. The SEP data payload is wrapped in the structure {'request': {'t_sep': $data}} according to the BPJS API specification. Basic error handling uses try-catch for RequestException.

Code 2: Sending Claim Data to E-Klaim INA-CBGs

Just like VClaim, E-Klaim also requires authentication. The payload structure for E-Klaim tends to be more complex because it includes detailed medical data.

<?phpnamespace App\pjs;use GuzzleHttp\Client;use GuzzleHttp\Exception\RequestException;class EklaimService{    protected $client;    protected $baseUrl;    protected $username;    protected $password;    public function __construct()    {        $this->username = env('BPJS_EKLAIM_USERNAME');        $this->password = env('BPJS_EKLAIM_PASSWORD');        $this->baseUrl = env('BPJS_EKLAIM_BASE_URL');        $this->client = new Client([            'base_uri' => $this->baseUrl,            'timeout'  => 10.0,        ]);    }    public function sendClaim(array $data)    {        try {            $headers = [                'Accept' => 'Application/json',                'Content-Type' => 'Application/json'            ];            // E-Klaim API often uses basic auth or custom auth in body/query string            // For demonstration, let's assume a token is needed or basic auth            // You might need to adjust based on specific E-Klaim API documentation            $authData = [                'user' => $this->username,                'pass' => $this->password            ];            $response = $this->client->post('/ws.php?bpjs=eklaim', [ // Example endpoint                'headers' => $headers,                'json' => array_merge($authData, ['data' => $data]) // Merging auth with claim data            ]);            return json_decode($response->getBody()->getContents(), true);        } catch (RequestException $e) {            return ['error' => $e->getMessage(), 'response' => $e->getResponse() ? json_decode($e->getResponse()->getBody()->getContents(), true) : null];        }    }}

Code Explanation 2: The EklaimService class manages interaction with the E-Klaim API. Note that authentication for E-Klaim can vary; some versions may use username/password in the request body or basic auth. This example combines the username and password directly into the claim data payload. The sendClaim method accepts a $data array containing the medical claim details. The endpoint /ws.php?bpjs=eklaim is an example; make sure you use the correct endpoint according to the latest E-Klaim documentation. It is important to ensure that all ICD-10 diagnosis codes and ICD-9-CM procedure codes submitted are valid and match the patient's case, as this is the main source of claim rejections in E-Klaim. Error handling is also implemented to catch network issues or invalid API responses.

Data Validation, Error Handling, and Example Payload

Strict data validation is the frontline for reducing claim rejections. Before sending data to the BPJS API, your SIMRS must perform a series of internal validations. This includes checking the format of ICD-10 and ICD-9-CM codes, the completeness of patient demographic data, the consistency of service dates, and the validity of referrals. Even the smallest inaccuracy can trigger a rejection. For example, a diagnosis code that is not listed in the latest ICD dictionary, or a patient discharge date that is earlier than the admission date.

The following is an example of a realistic JSON payload sent to the E-Klaim API for the INA-CBGs grouping process. Pay attention to the details of the diagnoses and procedures:

{  "metadata": {    "method": "new_claim",    "nomor_sep": "0301R00109190000001"  },  "data": {    "nomor_kartu": "0001234567890",    "nomor_rm": "RM0012345",    "nama_pasien": "Budi Santoso",    "tgl_lahir": "1980-05-15",    "gender": "1",    "jenis_rawat": "1",    "kelas_rawat": "2",    "tgl_masuk": "2024-03-01 10:00:00",    "tgl_keluar": "2024-03-05 14:30:00",    "diagnosa": [      { "kode": "I10", "level": "utama" },      { "kode": "E11.9", "level": "sekunder" }    ],    "prosedur": [      { "kode": "88.72", "level": "utama" },      { "kode": "89.52", "level": "sekunder" }    ],    "tarif_rs": 5000000,    "tarif_poli_eksekutif": 0,    "dokter_dpjp": "1234567",    "kode_ppk_pelayanan": "0301R001",    "berat_lahir": 0,    "admittance_weight": 65,    "discharge_weight": 64,    "discharge_status": "1",    "spesialistik": "01",    "rujukan": "1",    "catatan": "Pasien hipertensi dengan diabetes melitus tipe 2."  }}

Example error message from the BPJS API: {"metadata":{"code":"400","message":"Diagnosa Utama tidak ditemukan atau tidak valid."},"response":null}. This error message is very specific, indicating that the ICD-10 code for the primary diagnosis (for example, I10) may not be listed or does not comply with the applicable INA-CBGs grouping rules. This can happen if there is a typo, the code is no longer active, or it does not match the context of the type of care.

Effective error handling includes: First, proactive SIMRS-side validation must detect these issues before submission. Second, if an error occurs from the BPJS API, the bridging system must be able to parse the error message and present it to the user (coder/claim admin) in an easy-to-understand format, complete with recommendations for correction. Third, implement a comprehensive logging mechanism, recording every request, response, and error detail, including the timestamp and full payload. This is very helpful in the debugging and audit process. Fourth, for temporary errors (for example, network issues), the system must have an automatic retry mechanism with gradual time delays. Fifth, provide an interface in the SIMRS that allows coders to correct rejected claim data and resubmit it easily.

Best Practices for Reducing Claim Rejections

1. Automatic Data Validation in SIMRS: Implement strict validation on every data input in SIMRS, especially for ICD-10 diagnosis codes and ICD-9-CM procedures, service dates, and patient demographic data. Ensure your system has the latest ICD dictionary and performs format and code validity checks in real-time before data is saved or sent.
2. Synchronized Master Data Integration: Ensure master data such as the list of doctors, medical actions, medications, and service tariffs in SIMRS are always synchronized with the standards and data used by BPJS Kesehatan. Master data inconsistencies are often the trigger for unexpected claim rejections.
3. Regular and Continuous Human Resource Training: Educating medical staff, coders, and the claims administration team about accurate coding rules, understanding the latest INA-CBGs regulations (for example, PMK No. 59 of 2014, PMK No. 76 of 2016, PMK No. 51 of 2018), as well as how to fill out medical records completely and correctly is key. Up-to-date knowledge significantly reduces data input errors.
4. Real-time Monitoring System and Dashboard: Develop a monitoring dashboard that displays claim status in real-time, including successful, pending, or rejected claims. This feature allows your team to immediately identify rejection trends and take corrective action without waiting for monthly reports.
5. Comprehensive Logging and Audit Trail: Record every API transaction (request and response) in detail, including timestamp, full payload, and HTTP status. These logs are invaluable for investigation when claim rejections occur, helping trace where the error originated, whether from the internal system or the BPJS response.
6. Automatic and Intelligent Retry Mechanism: For temporary errors (for example, connection timeout or the BPJS server being busy), implement an automatic retry mechanism with an exponential backoff strategy. This will increase the probability of claims being successfully submitted without excessive manual intervention.
7. Routinely Conduct Internal Data Quality Audits: Conduct internal audits periodically on the quality of medical record data and claim data. Identify common error patterns, provide feedback to staff, and update validation rules in SIMRS to prevent the same errors from recurring.
8. Proactively Update the Bridging System: BPJS APIs and INA-CBGs regulations can change. Ensure your IT team always monitors official announcements from BPJS Kesehatan and proactively updates the bridging system so that it remains compatible and in accordance with the latest standards, avoiding compatibility issues in the future.
9. Optimize the Use of Cache for Static Data: For data that rarely changes such as the list of ICD codes or the list of PPK (Pusat Pelayanan Kesehatan), utilize caching on the SIMRS side. This will reduce the number of calls to the BPJS API, speed up the process, and reduce the load on the BPJS server.

FAQ (Frequently Asked Questions)

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

The main causes of INA-CBGs claim rejections often stem from data mismatch or inaccuracy. This includes errors in coding ICD-10 diagnoses and ICD-9-CM procedures, incomplete or invalid patient data, inconsistent service dates, or incompleteness of medical record files supporting the claim. Problems are also often found with invalid referrals or BPJS membership periods that have expired at the time of service.

2. How crucial is the role of medical coders in the INA-CBGs bridging process?

The role of medical coders is very crucial and cannot be replaced. Coders are responsible for ensuring that all patient diagnoses and medical procedures are coded accurately using the correct ICD-10 and ICD-9-CM standards. The accuracy of these codes directly affects the INA-CBGs grouping process and the determination of claim tariffs. Coding errors by coders are one of the biggest causes of claim rejections, so training and certification of medical coders need to be a priority.

3. How often is the BPJS Kesehatan API updated, and how can changes be monitored?

The BPJS Kesehatan API, both VClaim and E-Klaim, can be updated periodically to accommodate regulatory changes, feature additions, or bug fixes. The frequency is not always fixed, but it is important for bridging system developers to actively monitor official announcements from BPJS Kesehatan through the developer portal or communication forums provided. Subscribing to related mailing lists or discussion groups can also help obtain update information more quickly and make system adjustments proactively.

4. Can the existing INA-CBGs bridging system be integrated with the SatuSehat initiative?

Conceptually, INA-CBGs bridging and SatuSehat integration have different objectives, but both are related to health data exchange. A bridging system designed with a modern architecture and using data standards such as FHIR R4 (Fast Healthcare Interoperability Resources) will be easier to adapt or integrate with the SatuSehat ecosystem in the future. Although currently BPJS still uses a specific API format, building a data foundation that complies with international standards will be very beneficial for long-term interoperability.

5. What is the estimated investment needed to develop or implement a reliable bridging system?

The investment required for a reliable bridging system varies greatly, depending on the complexity of the existing SIMRS, whether it will be developed from scratch or integrate a third-party solution, as well as the capacity of the internal development team. However, keep in mind that investment in a solid and efficient bridging system will provide significant long-term cost savings from reduced claim rejections, improved cash flow, and operational efficiency. Consider this a strategic investment, not just an operational cost.

6. How can patient data security be ensured during the bridging process with the BPJS API?

Ensuring patient data security is the top priority. Use HTTPS (SSL/TLS) connections for all API communications to encrypt data in transit. Implement strong API authentication using securely managed API Keys and Secrets, and ensure no sensitive information is exposed in logs or URLs. In addition, comply with applicable personal data protection regulations, such as the Personal Data Protection Law (UU PDP), and conduct regular system security audits to identify and address potential vulnerabilities.

INA-CBGs Bridging Optimization: A Strategic Investment for Healthcare Facility Efficiency

Understanding how INA-CBGs bridging works and implementing strategies to reduce claim rejections is not merely a technical task, but a strategic investment that is fundamental to the sustainability and operational efficiency of your healthcare facility. From a solid technical architecture, accurate code implementation, to the adoption of best practices in data validation and human resource training, every aspect plays a crucial role. A reliable bridging system will ensure stable cash flow, minimize administrative workload, and allow you to focus on the core of patient care.

If you are facing challenges in optimizing your INA-CBGs bridging system, or are looking for a SIMRS/SIM Klinik solution that is fully integrated and able to meet the latest regulatory standards, do not hesitate to take the next step. With more than a decade of experience in developing healthcare IT solutions, Nugroho Setiawan and the team are ready to be your partner. We offer expertise in BPJS/SatuSehat/FHIR integration and system development tailored to your specific needs. Visit our website at nugrohosetiawan.com or contact our team for a free consultation and discover how we can help you achieve operational efficiency and significantly reduce claim rejections.

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