KlaimLolos — INA-CBG claim screen for Indonesia’s small private hospitals

1. One-liner

Catches the coding and document gaps a BPJS verifier will reject — before the claim leaves the hospital.

2. Trend signal — why now?

Three things converged in the last 12–18 months.

The pain is measured, not anecdotal. Indonesian academic studies put the BPJS pending-claim rate at ~10.2%, with ~33% of pending cases caused specifically by clinical coding errors; separate hospital studies find claims coded by in-house coders run on average ~4% lower than a standard coder would assign — a silent revenue haircut on top of the cash-flow delay. Pending claims have a hard 6-month resubmission cliff, and delayed payment is repeatedly tied to hospitals struggling to pay salaries and buy drugs.

The data became machine-checkable. BPJS E-Klaim and the SatuSehat platform moved to structured APIs and now require SatuSehat medical-record validation before E-Klaim will calculate a claimable amount. The rules a verifier applies (code specificity, secondary-diagnosis consistency, supporting-document presence) are increasingly explicit and inspectable rather than locked in a verifier’s head.

Cheap clinical NLP in Bahasa arrived. Streaming Whisper-class transcription dropped to ~$0.006–0.017/min, and Indonesian/Indic-tuned ASR + LLMs (Sarvam/AI4Bharat-class, Bhasini-style stacks) make parsing free-text Bahasa resume medis into structured ICD-10 / ICD-9-CM candidates economically viable for the first time at clinic-tier price points.

Provenance:

• Signal 1 (demand): ~10.2% BPJS pending-claim rate, ~33% from coding errors; in-house coding ~4% below standard = direct revenue loss + 6-month resubmission cliff — https://jurnal.uimedan.ac.id/index.php/JIPIKI/article/view/2164 ; https://ejournal2.litbang.kemkes.go.id/index.php/hsji/article/view/464 — 2026-05-16
• Signal 2 (feasibility): BPJS E-Klaim + SatuSehat now structured APIs with SatuSehat MR validation gating claimable amount — https://satusehat.kemkes.go.id/platform/docs/id/interoperability/klaim-bpjs/ — 2026-05-16
• Signal 3 (economic): Indonesian clinic-software market is funded and consolidating (Klinik Pintar $5M Series A1, 1,500+ partner clinics; Assist.id, eClinic active) but selling full EMR suites, not focused claim assurance — https://asiatechdaily.com/indonesias-klinik-pintar-secures-5m-in-series-a1-funding-to-propel-healthtech-expansion/ — 2026-05-16 Category: Workflow automation

3. The opportunity

US revenue-cycle vendors built a multi-billion-dollar category on one idea: scrub the claim before the payer sees it (Waystar, AdvancedMD, Availity edits). Indonesia has the same payer-rejection economics under BPJS INA-CBG — but no equivalent focused product. The incumbents here (eClinic, Assist.id Clinica, Klinik Pintar AKP) sell full EMR suites: registration, EMR, inventory, queue, then claim submission as one feature among twenty. None of them sells, or markets, a sharp pre-submission “this claim will get rejected, here’s why, fix these three things” layer.

That gap is the wedge. A focused tool that ingests the encounter (resume medis + diagnoses + procedures + attached documents) and returns a verifier’s-eye rejection prediction with the specific fix — code too non-specific, secondary diagnosis inconsistent with primary, missing supporting examination, ICD-9-CM procedure mismatch — sits next to whatever the hospital already runs (including paper/Excel + the BPJS portal). It attacks recurring cash leakage, not a one-time digitization project, so it’s a standing line item, not a migration the buyer dreads.

The non-obvious reason it’s fresh: the suite vendors are structurally disincentivized to build this well. A cheap, standalone “you’re leaving 4% on the table and here’s the exact fix” product cannibalizes the upsell story that justifies their per-seat suite pricing. A focused outsider has no such conflict.

4. Target market

• Primary customer: Casemix/claim-admin lead or finance manager at private FKRTL — klinik utama and small private hospitals (RS kelas C/D, <100 beds) in Indonesia that bill BPJS on INA-CBG per-episode tariffs. These are the facilities where coding errors directly burn cash, unlike kapitasi-paid klinik pratama (prepaid per-head).
• Why they buy: “Setiap bulan ada klaim pending, admin capek revisi berkas, kas terlambat” — every month a slice of claims comes back pending, the admin team is exhausted re-working files, and cash arrives 1–6 months late. They already know coding competency is the root cause; the cited fix in the literature is “better coordination and coder training” — i.e., there is no product, just an exhausted human.
• Rough TAM reasoning: Indonesia has on the order of 3,000+ hospitals, the majority small/private RS kelas C/D, plus a growing klinik utama tier — call it 3,000–5,000 INA-CBG-billing FKRTL facilities as the serviceable target. At a few hundred USD/mo this is a comfortably sub-$5M-ARR niche that’s too unsexy for the suite players to defend hard.
• Why now for them: SatuSehat/E-Klaim structuring made claims machine-validatable; accreditation pressure already forced many onto digital MR; and the 6-month resubmission cliff plus salary/drug cash-flow pain makes a “stop the leak” pitch land this quarter, not “transform your operations someday.”

5. Product sketch (MVP)

• Upload or paste a batch of encounters (resume medis text + assigned ICD-10/ICD-9-CM + attached document list); Bahasa free-text supported.
• Rejection-risk score per claim with a ranked, plain-Bahasa list of the specific issues a BPJS verifier will flag.
• Coding second opinion: where the documentation supports a more specific or higher-yield (non-fraudulent) code than the coder assigned, surface it with the supporting sentence highlighted.
• Missing-document checklist tied to the diagnosis/procedure (the single biggest cited cause: ~37% of inaccuracy = missing supporting docs).
• “Verifier disagreement” pattern memory: learns this facility’s own historically returned-claim patterns from uploaded BPJS pending letters and warns on repeats.
• One-click export of the corrected coding + document gap list back into the hospital’s existing workflow (copy/paste or CSV; no rip-and-replace of their EMR).
• Monthly leakage report: rupiah recovered / at-risk this period, for the finance manager who signs the renewal.

6. AI angle — what’s load-bearing

Remove the AI and the product does not exist. The core is a model that reads unstructured Bahasa clinical documentation and reasons about the gap between what was documented, what was coded, and what a BPJS verifier will accept under INA-CBG / ICD-10 / ICD-9-CM rules. That is exactly the judgment a scarce, expensive trained coder applies — the literature names “low coder competency” as the root cause. A rules engine alone can’t do it (the failures are semantic: non-specific diagnoses, primary/secondary inconsistency, documentation that doesn’t substantiate the code). LLM clinical-text reasoning + a curated INA-CBG/verification rulebase is the product; everything else is plumbing.

7. Localization angle

This is inherently Indonesia-first and that is the moat. INA-CBG grouper logic, BPJS verification practice, SatuSehat/E-Klaim interop, and the Bahasa clinical documentation style are all Indonesia-specific. A generic global claim scrubber (US CPT/ICD-10-CM, commercial payers) cannot serve this market without a ground-up rebuild. Pricing must be local: an IDR 1.5–4M/mo tier reads as cheap against even one recovered pending claim, where a US-priced tool would be a non-starter. Distribution leans on Indonesian channels — PERSI (hospital association) workshops on INA-CBG coding already exist and are where this buyer congregates.

8. Business model — path to $1M–$5M ARR

• Pricing: IDR 2,500,000/mo ($155) base for a small RS kelas C/D, scaling to IDR 5,000,000/mo ($310) for higher claim volume / multi-site. Anchored as a fraction of one month’s recovered leakage.
• ACV: ~$2,200–3,700/yr per facility.
• To $1M ARR: ~350 facilities at ~$2,800 ACV ≈ $1.0M. Out of a 3,000–5,000 facility target, that’s ~7–10% penetration — achievable for a focused niche tool with a hard ROI story.
• To $5M ARR: ~1,200–1,500 facilities (heavier penetration plus an upsell tier), or add a per-recovered-claim success component and expand from RS kelas C/D into klinik utama and BPJS-adjacent private-insurer claims (which share the documentation-substantiation problem).
• Expansion path: seats for larger casemix teams; success-fee tier on recovered rupiah; private-insurer claim module; a benchmarking report (“your reject rate vs peer RS kelas C”) as a sticky paid add-on.

9. Go-to-market wedge — first 100 customers

• Free reject audit on real claims. Offer to run a hospital’s last 200 BPJS claims through the screen and hand back a rupiah-quantified leakage report. The output is the sales pitch; the literature already primed the buyer to believe coding loses them money.
• PERSI / casemix-coder training circuit. INA-CBG coding workshops (PERSI, Diklat casemix providers) are where exactly this buyer already pays to send staff. Sponsor/present, then convert attendees — they arrive pre-convinced the problem is real.
• Direct outreach to RS kelas C/D finance managers. Hospital directories + Kemenkes facility lists are public; target the ~3,000 small private RS with a one-page “you are losing ~4% of BPJS revenue to coding — here’s proof on your own claims” message.
• Casemix consultant / verifier-trainer partnerships. The independent trainers who teach coding for a living can resell or refer the tool as the thing that makes their training stick between sessions.
• Land via one regional hospital group, prove recovered rupiah, use that as the reference case for the rest of that province’s private RS.

10. Build complexity — justification

Medium. Off-the-shelf: LLM clinical reasoning, ASR for Bahasa, standard web stack, document checklist logic. Custom and non-trivial: curating and maintaining an accurate INA-CBG / ICD-10 / ICD-9-CM verification rulebase that mirrors how BPJS verifiers actually behave (not just the published spec — the tacit disagreement patterns), and tuning the model so its code suggestions are defensibly non-fraudulent. Realistically a small team (1 domain coder/casemix expert + 1–2 engineers) ships a credible v1 in ~4–6 months; the rulebase quality, not the software, is the long pole and the moat.

11. Gating checklist

Gate	Pass?	Note
Legal in target market	✅	Advisory pre-submission tool; the hospital still files via official BPJS channels. No regulated submitter status needed.
Ethical — no harm / dark patterns	✅	Suggests only documentation-substantiated codes; explicitly anti-upcoding/anti-fraud framing.
Market exists (evidence above)	✅	Measured 10.2% pending rate, ~4% revenue loss, funded suite market — demand is documented, not hypothetical.
1–5 person team can build this	✅	1 domain expert + 1–2 engineers, ~4–6 months to v1.
Launchable with <$50K / ₹40L	✅	Off-the-shelf APIs; main cost is the domain expert’s time to build the rulebase.

All five pass.

12. Feasibility score

Axis	Weight	Score	Notes
Problem intensity	20	17/20	Hair-on-fire for FKRTL: measured recurring revenue loss + cash-flow delay tied to paying salaries/drugs. Just short of 18+ because kapitasi-paid clinics are immune, narrowing the true buyer to INA-CBG facilities.
Demand evidence	15	12/15	Strong: peer-reviewed Indonesian studies quantify reject rate and revenue loss; funded suite market. Knocked from 13+ because the evidence is academic/structural, not yet verbatim “shut up and take my money” operator quotes.
Build feasibility	15	10/15	Software is standard; the verification rulebase that mirrors real BPJS verifier behavior is a genuine multi-month domain effort, not a weekend API wrapper.
Distribution clarity	15	11/15	Named channels (PERSI workshops, public RS directories, free-audit wedge) with a hard ROI hook. Not 13+ because hospital procurement, even small private, has a sales cycle measured in weeks-to-months, not days.
Revenue mechanics	15	12/15	Pricing benchmarks cleanly against recovered rupiah; ACV and customer count to $1M are realistic. One assumption (small RS will pay a SaaS subscription vs demand success-fee-only) still a guess.
Time to first revenue	10	7/10	Free audit → paid can close in 4–8 weeks once the rulebase is credible, but the rulebase must exist first, pushing first revenue past the trivial-launch window.
Defensibility	10	7/10	Soft but real: the curated verifier-behavior rulebase + accumulating per-facility reject-pattern data compounds; suite incumbents are conflicted from competing hard. Not 9+ because a determined funded player could replicate the rulebase.
Total	100	76/100

13. Qualitative modifiers

Founder-fit tags

domain-expertise-required · technical-heavy — needs someone who genuinely understands INA-CBG coding and BPJS verification practice (an ex-casemix lead or verifier), paired with engineering. Without the domain seat the rulebase will be wrong and the product is worthless.

Key assumptions to validate (3–5)

1. Assumption: Small private RS will pay a recurring SaaS fee (not only success-fee) for pre-submission assurance. How to test: Free audit on 15 hospitals’ real claims; offer a 3-month paid pilot; measure how many convert to a subscription vs only accepting success-fee terms.
2. Assumption: An LLM + curated rulebase can predict BPJS verifier rejections with enough precision to be trusted (high precision, low false-alarm). How to test: Run the screen blind on a historical set of claims with known BPJS outcomes; require ≥80% catch on actually-rejected claims with a tolerable false-positive rate before charging.
3. Assumption: The recoverable leakage per facility is large enough to dwarf the subscription. How to test: Quantify rupiah-at-risk in the free audits; need average recoverable/month ≥ 3× monthly price to make the pitch trivial.
4. Assumption: Suite incumbents won’t bundle an equivalent for free fast enough to kill the wedge. How to test: Track eClinic/Assist.id/Klinik Pintar release notes and sales messaging over the pilot period.

Risk flags

1. Regulatory/platform dependency: BPJS can change INA-CBG grouper logic, verification rules, or E-Klaim/SatuSehat APIs; the rulebase needs continuous maintenance — this is also the moat, but a real ongoing cost.
2. Trust/liability: A wrong “this is fine” that still gets rejected, or a code suggestion that looks like upcoding, damages credibility fast. Conservative, documentation-anchored suggestions and clear anti-fraud framing are non-negotiable.
3. Market timing vs incumbents: Assist.id already ships an “AI Vera” voice-to-EMR with ICD-9 procedure suggestion inside its suite. The standalone, sharper, payer-rejection-focused angle is the differentiator — but the window to own that positioning is finite.

14. Structured verdict

Score:                  76/100
Verdict:                GO
Confidence:             Medium
Best-fit builder:       Ex-casemix lead / BPJS verifier paired with a technical founder
Time to revenue:        ~10–16 weeks (rulebase build, then free-audit → paid pilot)
Capital to launch:      ₹4–6 lakh / $5–7K (mostly domain-expert time + API costs)
Top 3 assumptions to validate first:
  1. Small RS pay recurring SaaS, not success-fee-only — 15-hospital free-audit + paid-pilot conversion test
  2. Screen catches ≥80% of actually-rejected claims at tolerable false-positive rate — blind backtest on known-outcome claims
  3. Recoverable leakage ≥3× monthly price — quantify in free audits
Kill criteria:
  - Abandon if <3 of 15 free-audit hospitals convert to a paid pilot
  - Abandon if rejection-prediction recall stays <70% on the blind backtest after rulebase iteration
  - Abandon if a suite incumbent ships an equivalent standalone-quality scrubber free before paid v1

15. Next step — 1-week validation sprint

• Day 1–2: Recruit the domain seat (ex-casemix lead/verifier). With them, hand-build a minimal rulebase covering the top 20 INA-CBG rejection patterns from the cited studies (non-specific primary dx, secondary-dx inconsistency, missing supporting docs, ICD-9-CM procedure mismatch).
• Day 3–4: Get 100–200 historical claims with known BPJS outcomes from 1–2 friendly small RS. Run the prototype screen blind; measure recall on actually-rejected claims and the false-positive rate.
• Day 5: Go / no-go on a falsifiable bar: ≥80% of actually-rejected claims flagged with a false-positive rate the casemix lead judges workable. If the model can’t see the rejections the verifiers saw, the product can’t exist — kill or rework before building anything else.