Insurance claims automation: document AI and RAG reduce adjudication from days to hours
Claims processing slows when adjusters spend 60% of their time manually entering medical documents into systems and checking policy terms line by line. This case study details a live insurance claims AI system: a three-layer confidence-scoring approach for medical documents, RAG-based policy retrieval for adjudication, and the results - average cycle reduced from 3.8 days to 5.2 hours, with the same team handling nearly three times the volume.
By
Tenten AI 交付團隊
產業交付
Published
December 14, 2025
Read time
5 分鐘

The claims department's real pain isn't judgment, it's speed.
A hospital insurance claim moves through the traditional process in three to five working days. The delay doesn't stem from poor judgment by claims adjusters. It happens because they spend 60% of their time on a single task: manually typing information from diagnosis certificates, medical expense receipts, medical records summaries, and surgical consent forms into the claims system, then systematically checking each line against policy terms and exclusions. Judgment takes 40% of their time. Data entry takes 60%. Automating that 60% back to machines is where insurance claims automation creates actual value.
Timeline and headcount after launch
We took over the health claims line at a mid-sized life insurance company. The baseline before implementation showed:
| Metric | Pre-Launch | 90 Days Post-Launch |
|---|---|---|
| Average decision cycle | 3.8 business days | 5.2 hours |
| Manual handling time per claim | 22 minutes | 6 minutes |
| Document extraction accuracy | ~97% manual | 94% initial AI extraction, 99.2% post-review |
| Claims requiring manual intervention | 100% | 38% |
| Claims per adjuster per month | ~380 per person | ~1,050 per person |
The final row matters most. We didn't eliminate any adjuster positions. The same team processed nearly three times the volume, with freed capacity redirected to cases requiring human judgment: disputed claims and high-value cases.
Document extraction: working with multiple document types
Medical documents represent the most difficult piece of claims automation. Taiwan's diagnosis certificates don't follow a standard format; every hospital has its own template layout, with handwritten notes, seals, and faxed scans mixed in. Our initial approach combined a general-purpose OCR tool with a large language model. The result was predictable: ICD diagnostic codes were misread, 'self-pay' and 'NHI-covered' columns on expense receipts were confused, and a single misaligned field caused incorrect payout amounts.
We restructured this into three layers. The first layer classifies the document type: diagnosis certificate, receipt, or medical record. The second layer extracts fields at the structural level - disease name, ICD code, admission and discharge dates, procedure name, and cost items. The third layer assigns a confidence score to every extracted field. Any field below the threshold gets flagged for human review. This confidence layer is what makes the system trustworthy to the claims department. Success isn't AI that's always correct. Success is AI that knows where it might be wrong.
Adjudication: connecting policy terms to claims decisions
Extraction produces clean data. Adjudication means taking that data and matching it against the policy. Is this covered? Has the waiting period passed? Does this procedure count as 'major surgery' under the policy definition? Does a pre-existing condition exclusion apply? These answers scatter across policy language, endorsements, internal underwriting rules, and precedent cases.
We used a RAG knowledge system to make the full policy text, claims guidelines for that insurance type, and internal decision standards searchable as a knowledge base. When the system finishes extracting a document, it retrieves relevant policy passages connected to that claim and shows them with the reasoning: whether to approve, which specific clause applies, which fields are being compared. The adjuster reviews a documented, traceable recommendation rather than interpreting a black box.
Our decision rule was clear. Low-value, straightforward claims with high confidence scores go to automatic approval. High-value cases, cases with disputed exclusions, or low-confidence scores always go to a person. Pursuing 100% automation in year one creates compliance risk that cannot be justified.
Adoption after launch
Building the system is one part of the project. Adoption is the rest. Many claims automation implementations perform well during testing, then adjusters return to manual processing after three months because they don't trust the system, the interface doesn't fit existing workflows, or there's no way to report issues. Engineers need to sit in the claims department for the first weeks post-launch: calibrating confidence thresholds, fixing misread document templates, and feeding disputed claims back into the model. The project succeeds when the system is live, people use it daily, and cycle time actually drops from days to hours.
This approach to financial claims automation requires embedding engineers in the claims operation until the system is live and staff actually use it, rather than providing a platform for independent operation.

One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.