Tutorial: Real-Time BPJS Claim Monitoring Dashboard for Hospitals & Clinics

Hospital IT managers usually only find out there are dozens of BPJS claims with pending status when the finance department reports that last month's claim funds have not been disbursed. In a type C hospital with a volume of 300–500 claims per month, a 2–3 day delay in claim submission alone can postpone the disbursement of Rp1.2–2.5 billion. A real-time claim monitoring dashboard closes this gap: instead of waiting for weekly Excel reports, it shows the status of every claim — from issued SEP, INA-CBG coding, E-Klaim verification to payment status — in seconds. This article discusses a technical implementation that can be retrofitted to an existing SIMRS without disrupting the daily operations of the casemix unit.

Why BPJS Claim Monitoring Must Be Real-Time

The BPJS Kesehatan claim flow has many bottleneck points: SEP is created but the diagnosis has not been coded, coding is complete but has not been grouped into INA-CBG, grouping is done but the file has not been submitted to E-Klaim, or it has been submitted but is subject to pending verification from the verifier. Each of these points, if not monitored manually, will pile up. Weekly monitoring via Excel risks letting claims dormant for 5–10 days before detection — and that is immediately felt in cash flow.

There are two data sources for the dashboard: the SIMRS database (MySQL 8.0+ or SQL Server 2019+) that stores SEP transactions, ICD-10 diagnoses, ICD-9 procedures, and local INA-CBG grouping results; and the BPJS E-Klaim/V-Claim API responses (Kemenkes Web Service for V-Claim, or E-Klaim WSDL version 5.9 and above). For a daily operational dashboard, about 90% of metrics are sufficient to be taken from the local database — the BPJS API is only used to synchronize final status (LAYAK, TIDAK LAYAK, BAYAR) so that it does not hit rate limits or IP blocks.

Mandatory metrics on the first screen: number of claims today, claims pending verification for more than 3 days, running claim value, average turn-around-time (TAT) from SEP to submit, and top 10 diagnoses with the highest pending. With these five numbers, operations managers can immediately call the responsible coder or verifier, without scrolling through a 3,000-row Excel. Add a filter per polyclinic (ER, inpatient, outpatient) so that the drill-down is clear.

Backend Implementation: Node.js + Socket.io + PostgreSQL

The simplest pattern we use at many SIMRS clients: a Node.js service stands beside SIMRS, reads the database with a read-only user, then broadcasts changes via WebSocket. Do not query the main klaim_bpjs table every 1 second — that burdens the transaction DB that is serving patient registration. Create a summary table klaim_bpjs_ringkas that is refreshed by a trigger or cron every 15 seconds, then the service only reads that summary table. As a result, the dashboard query is < 50 ms even with a claim volume of 10,000 rows per month.

The stack we recommend for this article: Node.js 20 LTS, Express 4.19.2, Socket.io 4.7.5, mysql2 3.9.7 (or pg 8.11.5 for PostgreSQL 16). A lightweight polling pattern with a 15-second interval is much easier to maintain than CDC Debezium — suitable for hospitals that have 1–2 IT support staff, not a large data engineer team. For volumes below 500 claims/day, 15-second polling will not burden anything.

// watcher.js — Node.js 20, mysql2 3.9, socket.io 4.7
import mysql from 'mysql2/promise';
import { Server } from 'socket.io';

const db = await mysql.createPool({ host:'10.0.0.5', user:'report', password:'***', database:'simrs' });
const io = new Server(3001, { cors: { origin: 'https://dash.rs.local' } });

setInterval(async () => {
  const [rows] = await db.query(
    `SELECT no_sep, status, biaya, updated_at
     FROM klaim_bpjs_ringkas
     WHERE updated_at > NOW() - INTERVAL 15 SECOND`
  );
  if (rows.length) io.emit('klaim:update', rows);
}, 15000);

For security, this service must not be exposed to the internet. Install it on an internal VLAN, enable JWT authentication on the Socket.io handshake, and audit connecting IPs. For production, run it on PM2 or Docker Compose with a /healthz healthcheck. Add Redis 7.2 pub/sub if the dashboard is scaled to more than one Node instance.

Frontend Dashboard with Chart.js and Server-Sent Updates

The frontend can simply be static HTML served via Nginx 1.26, with Chart.js 4.4.2 for visualization. Three mandatory widgets: a bar chart of claims per status (draft, submit, pending, layak, bayar), a line chart of claim value per day for the last 30 days, and a live table of the 20 most recently changed claims. Do not over-design; managers need numbers they can scan in 5 seconds, not animations.

Connect the Socket.io client, and on the klaim:update event, push data to an in-memory array. Update the chart with chart.data.datasets[0].data = ...; chart.update('none');. The 'none' mode prevents repeated animations that make the dashboard feel slow when updating every 15 seconds. For the table, use simple virtual scrolling if rows > 200, or paginate 20 rows per page.

Add threshold-based alerts: if pending claims > 50 within 1 hour, send a notification via WhatsApp Business API or email to the casemix supervisor. This is what distinguishes a beautiful dashboard from a useful dashboard. A correct dashboard will reduce claim submission TAT from an average of 4.5 days to 1.8 days in the first 2 months — a real number from our last project at a type C hospital in DKI Jakarta with a volume of 420 claims/month.

Best Practices

1. Create a read-only DB user specifically for the dashboard service; do not use SIMRS application credentials.
2. Use a summary table (aggregate table) refreshed every 15–30 seconds, not live queries to transaction tables.
3. Store an audit log of every claim status change in the klaim_histori table for internal verification needs.
4. Implement JWT and TLS authentication on Socket.io; do not expose ports to the public internet.
5. Create threshold alerts for pending more than 3 days and send them to the casemix supervisor every morning at 08.00.

FAQ

Can this dashboard be integrated with E-Klaim BPJS?

Yes. Synchronization to E-Klaim or V-Claim is done via cron once every hour to fetch the latest LAYAK/TIDAK LAYAK/BAYAR status. Do not poll the BPJS API every second — there is a rate limit and risk of IP blocking. Store the synchronization results in the klaim_bpjs_sync table and then broadcast them to the dashboard via the same Socket.io event.

What is the minimum infrastructure cost?

For a type C hospital with 300–500 claims/month, one on-premise VM with 4 vCPU / 8 GB RAM is sufficient. Stack: Ubuntu 22.04, PostgreSQL 16, Node.js 20, Nginx 1.26, Redis 7.2 (optional). Cloud costs are around Rp800.000–1.500.000 per month; on-premise is cheaper because it can run on the existing SIMRS server.

What if SIMRS does not have triggers or stored procedures?

Use SELECT polling based on the updated_at or last_modified column. The requirement is that the BPJS claims table has a timestamp column that is updated when the status changes. If SIMRS does not have it, add that column via alter table — it is safe and does not disrupt the old application. Fill its value via a lightweight trigger or via the application on the form side.

How long does implementation take until production?

With a team of 1 backend + 1 frontend, the MVP dashboard (5 metrics, 3 widgets, WhatsApp alerts) is completed in 2–3 weeks. The next iteration for drill-down modules per polyclinic and per coder usually takes an additional 1–2 weeks. The main determining factors are the quality of the DB connection and the consistency of claim status naming in SIMRS.

The BPJS claims monitoring dashboard is not a large project — for many of our clients, the MVP is completed in 2–3 weeks and immediately reduces claim submission TAT significantly. The keys to success are a lightweight summary table, secure WebSocket, and well-targeted alerts. If you want to implement a similar dashboard in a hospital or clinic without disrupting the existing SIMRS, consult your needs with the Nugroho Setiawan team — we help from aggregate schema design, Node.js service, to the Chart.js frontend used daily by casemix managers and finance staff.

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