Knowledge Engineering — Hospital ICD-10-TM

Where AI Actually Earns Its Keep
in Hospital Revenue Cycles.

Chart documents one thing. Claim pays for another. AI takes the pre-submission audit role — explainable, built for Thai hospital revenue cycle teams.

The Silent Leak

The claim paid. It just paid less than it should have.

A 65-year-old patient is admitted with MRSA pneumonia. The doctor documents the pathogen in the progress notes. Antibiotic therapy runs for ten days. The discharge summary, written quickly at end of shift, mentions ‘bacterial pneumonia’ without naming the organism. The coder, working from the discharge summary as most do, assigns a less-specific code set — and misses the secondary diagnosis that would have promoted the encounter to a higher DRG severity tier under TDRG v6.3.

The claim is not denied. It pays. It just pays less than it should have. The chart fully supported the higher tier; the coding didn’t carry the evidence forward. The hospital absorbs the gap as ‘lower DRG mix’ — a category that, by design, looks unattributable.

This pattern repeats across a hospital’s monthly claims at a rate the hospital itself rarely knows, because the underpayment is silent. The claims dashboard shows ‘paid.’ The cash flow shows the gap.

This article is for hospital executives and finance leaders asking a specific question: ‘There are dozens of AI vendors. Which AI actually pays for itself, and how do I verify it before I commit?’ The answer below uses real Thai payer mechanics — ICD-10-TM, TDRG v6.3, CSMBS — without putting fabricated baht numbers on outcomes we haven’t yet measured on your data.

Where the Money Leaks

Three categories. All measurable on your own data.

All three are under-reported in standard revenue-cycle dashboards.

Severity-tier underpayment

Every DRG under TDRG v6.3 has a tier ladder. Moving from a lower to higher tier on the same DRG can add a material amount per encounter — the exact delta varies by DRG and payer fee schedule. Promotion requires specific secondary diagnoses the chart often supports but the coder may have missed. Invisible in most dashboards because the claim paid — just at the lower tier.

Drug-diagnosis denials

Pharmacy claims for high-cost drugs are routinely audited retrospectively. If the encounter codes don’t carry a diagnosis that justifies the drug, the payer claws back the pharmacy charge — sometimes months after the encounter, when documentation can no longer be clarified.

Cross-DRG routing errors

When the primary diagnosis is coded under-specifically, the encounter sometimes routes to an entirely different (lower-paying) DRG than the chart evidence supports. These are typically the largest single leaks per encounter.

Now translate the volume side into monthly impact — separately from the per-encounter dollar figures, which depend on your DRG mix and payer schedule. Take an illustrative mid-sized hospital: 300 beds, ~3,000 encounters per month, 8% coding-related denial rate (industry experience suggests 5–10%; substitute your own). That’s roughly 240 denied claims a month sitting in receivables purgatory.

Each denial triggers a fix-and-resubmit cycle averaging 45 minutes of certified-coder labor — roughly 180 hours a month unwinding prior work. Certified ICD-10-TM coders are not abundant in the Thai market; you cannot hire your way out of this. And the cash impact compounds: a claim that pays in 30 days when clean takes 60–90 when it bounces. At any moment, a meaningful share of monthly revenue is parked in rejected-claim AR — working capital the hospital is financing instead of using.

Three leaks. The volume side is yours to quantify from your existing data today. The per-encounter recovery is what the pilot measures.

Where We Plug In

One audit, three checks, between coder and payer.

Doctor writes note Coder assigns codes STAGE 1 Note-to-code suggestion helps at coding time STAGE 2 Pre-submission audit 3 checks against TDRG · formulary Submit claim out Payer CSMBS / UC / SSS Paid correct tier Rejected → rework loop STAGE 3 Denial remediation helps fix rejections Stage 2 — the 3 audit checks (rule-based, against TDRG v6.3 + formulary) ① severity-promoter gaps ② drug-dx alignment ③ primary-dx specificity

Three AI stages, one workflow. Each stage augments a specific point — coding (Stage 1), pre-submission (Stage 2), post-rejection (Stage 3).

After the coder assigns codes — using their own judgment, with whatever tools they currently use — the platform reviews the complete code set against three rule-based checks before the claim leaves the building.

Check 1

Severity-promoter gaps

For each DRG, TDRG v6.3 specifies which secondary diagnoses promote the case from lower to higher tiers. The audit cross-references the assigned secondaries against the documented chart and flags missing promoters. The coder sees the flag with citations to the chart passage that supports the missing secondary, accepts or overrides, and the claim ships at the correct tier.

Check 2

Drug-diagnosis alignment

The audit cross-references administered drugs against a formulary lookup of which diagnoses justify each drug. Drug administration without a corresponding diagnosis in the encounter is flagged before submission — not discovered later when the payer claws back the pharmacy charge.

Check 3

Primary-diagnosis specificity

When the coded primary routes to a different DRG than the chart evidence supports, the audit flags it. Under-specific primaries often route to lower-paying DRGs entirely.

One design choice matters more than any other for a CFO: these checks are rule-based, not LLM-inferred. The audit consults published Thai payer rules (TDRG v6.3, CSMBS fee schedule, formulary tables) and applies them mechanically. A finance team can look up the same rule and reproduce the same finding. Same input, same output, every time. The audit is not a black box and not a probabilistic guess — it’s a rule engine that consults source-of-truth tables you can verify yourself.

This is the answer to ‘how do we know the AI isn’t making things up.’ It isn’t generating diagnoses or interpreting clinical language. It’s checking the coder’s assignments against published rules and surfacing the gaps. The coder still makes the final call. The doctor still owns the chart. The audit just makes sure the chart’s documented value reaches the payer.

What the Pilot Measures

The number that matters is yours, not ours.

We don’t quote per-encounter recovery figures or annualized ROI in this article. We could — every AI vendor does. The reason we don’t:

Your DRG mix is yours. Severity-tier deltas depend on which DRGs your facility actually bills. A facility heavy in cardiology has a different recoverable surface than one heavy in orthopedics. Quoting an industry-average baht figure hides more than it reveals — and gives you a number to verify rather than your own number to use.

Your baseline rejection rate is yours. Until we measure it, we don’t know whether your facility sits at the bottom or top of the 5–10% range. Multiplying our guess by your volume produces an answer that’s neither yours nor useful.

Your documentation baseline is yours. A facility with strong CDI processes leaves less on the table than one without. The pre-submission audit captures more value at facilities with weaker baselines. We won’t pretend the same number applies to both.

What the 60-day pilot produces, on your data, on your hardware:

You walk out of day 60 with four numbers anchored to your operation. Those are the numbers your board will trust.

What This Is (and Isn’t)

A support layer for coders. Not a replacement.

The audit is a support layer for coders, not a replacement for them. The coder makes the final call. The doctor owns the chart. The platform inserts a rule-based check where checks didn’t exist before — so finance can audit the audit.

Two further capabilities are on the roadmap, named here because publishing creates accountability:

We won’t bill for these before they ship and won’t claim them as available in pilot conversations. If either lands earlier than planned, we’ll measure and publish.

Why an Executive Should Care

Three reasons, specific to a CFO/CIO audience.

1. Recovery is verifiable, not projected.

Most AI vendors selling into healthcare cannot show you a single encounter and walk you through the math from published rule to recovery. This audit can — because it isn’t generating predictions, it’s enforcing published rules you can look up yourself.

2. The data stays on-premise.

Under PDPA, patient data leaving the network is a non-starter. The audit runs on hardware the hospital provides — workstation-class GPU, single server, in your own data center. No cloud upload, no patient data exfiltration, no infosec review nightmare.

3. The pilot is bounded.

We’re opening pilot conversations with up to three Thai hospital partners for a 60-day measured trial. After day 60, you have a real measurement against your baseline. If the recovery doesn’t justify the effort, the pilot ends with no further commitment. If it does, we’ll have a conversation about ongoing operation based on actual numbers.

Pilot Program

Up to three pilot slots.
Bounded. Measurable. On-premise.

If the leakage patterns above sound familiar — silent severity-tier underpayment, drug-dx clawbacks discovered too late, denial-driven coder rework consuming your senior team's bandwidth — the first step is small.

We’re committing to a 2-business-day response on initial scoping. The first conversation is 30 minutes and is about fit: your encounter volume, payer mix, current denial baseline (you don’t need to know the exact number — we’ll measure it together), and whether the pre-submission audit pattern matches the leakage you suspect.

Start a Conversation

We welcome international engagements — serving clients across Southeast Asia and beyond.

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand