ClaimSense is a document-processing pipeline.

A claim arrives as a folder of scanned hospital documents.

The system reads every page, identifies what each page contains, extracts the relevant information, checks the documents against the submitted package, reconstructs the treatment timeline, runs the package rules, and produces a final decision.

The architecture is deliberately split between deterministic processing and AI.

AI is useful where the documents are difficult to understand.

It isn’t necessary for everything.

System Philosophy

Most claim-checking tools ask a version of:

Does this document exist?

ClaimSense asks something closer to what an auditor actually asks.

Does this claim tell a consistent story?

Everything downstream — classification, extraction, aggregation, the timeline and the rules — exists to answer that one question.

Product Architecture

The unit of work is the page.

Everything else is built on top of it.

                  Claim Folder
                       │
                       ▼
                 Split into Pages
                       │
                       ▼
              Deterministic Classifier
                       │
                 ┌─────┴─────┐
                 │           │
             Confident    Uncertain
                 │           │
                 │           ▼
                 │      Claude Vision
                 │           │
                 └─────┬─────┘
                       ▼
              Page-level Understanding
                       │
                       ▼
             Structured Claim Data
                       │
                       ▼
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
        Package Check      Timeline Check
              │                 │
              └────────┬────────┘
                       ▼
                 Package Rules
                       │
                       ▼
             PASS / FAIL / CONDITIONAL

The system does not ask a model to understand an entire claim in one shot.

It first makes every page understandable.

Then it assembles the claim.

Then it decides.

The Claim

A claim starts as a folder.

That folder might contain laboratory reports, prescriptions, discharge summaries, operative documents, identification documents, feedback forms and other hospital paperwork.

The first architectural decision is to turn that folder into something the system can reason about.

Claim
│
├── Document
│   ├── Page
│   ├── Page
│   └── Page
│
├── Extracted data
├── Package
├── Timeline
└── Decision

The page is the smallest meaningful unit.

This matters because different pages require different kinds of understanding.

A claim should not become dependent on one giant model call simply because it arrived as one folder.

Deterministic First

Most hospital documents are predictable.

A Widal test looks like a Widal test.

A discharge summary has a header that says so.

A feedback form has a recognizable structure.

These don’t require a language model to be recognised.

So the first pass is rules.

ClaimSense uses keyword and document-signature matching to classify pages where the evidence is strong enough.

Only when that layer isn’t confident does the page go further.

This isn’t primarily a cost optimization.

It is a responsibility boundary.

Don’t make a model responsible for something simpler logic can already determine.

Where Claude Comes In

Some pages aren’t predictable.

Scanned pages.

Poor-quality documents.

Handwriting.

Hindi and mixed-language notes.

Documents where the information is present, but not in a consistent format.

Those pages go to Claude’s vision model with the extraction instructions for the package being processed.

Claude performs OCR and document understanding together.

The important distinction is that Claude isn’t being asked:

Does this claim pass?

It is being asked:

What does this page say?

That keeps the model in the understanding layer of the system.

Structured Claim Data

Once pages have been classified and understood, their information is converted into structured claim data.

The system doesn’t want a collection of independent model responses.

It wants one representation of the claim.

Values such as dates, diagnoses, procedures, investigations and supporting evidence can then be used by the rest of the pipeline without repeatedly going back to the original document.

This is where individual pages become one claim.

Provenance

Nothing extracted by the model is treated as an unexplained fact.

Every relevant value carries its source.

That includes:

• The page it came from.
• The evidence that produced it.
• The model confidence associated with the extraction.

The provenance is not necessarily part of the final claim output.

It exists so that the system can answer a much more important question:

Why did ClaimSense reach this conclusion?

A PASS or FAIL should be explainable, not just asserted.

Package Validation

The submitted package is not treated as ground truth.

A hospital may submit a claim under a particular package.

The documents may tell a different story.

ClaimSense compares the submitted package with what the documents actually describe.

It also checks whether the required documents and evidence for that package are present.

This is an important distinction.

The system isn’t only checking whether files exist.

It is checking whether the files make sense for the package being claimed.

Extra Documents

Not every document in a claim folder is required.

A claim can contain additional paperwork that isn’t part of the package requirements.

ClaimSense identifies these documents separately.

They are marked as extra with a plain-English reason.

This prevents a simple document-counting system from confusing:

not required

with

missing.

The Treatment Timeline

Dates are not independent fields.

They describe a sequence.

ClaimSense therefore reconstructs the treatment timeline from the information extracted across the claim.

Admission
    ↓
Investigation
    ↓
Treatment
    ↓
Procedure
    ↓
Recovery
    ↓
Discharge

The exact events depend on the claim.

The important part is that they are considered together.

A date that looks valid by itself can become suspicious when placed next to the rest of the claim.

The timeline lets the rules reason about the sequence rather than individual documents in isolation.

Rules Decide

Once the claim has been classified, extracted and assembled, it goes through rules specific to its package.

The rules are where the decision is made.

Structured Claim
       │
       ├── Package requirements
       ├── Required documents
       ├── Clinical evidence
       ├── Dates
       ├── Timeline
       └── Consistency checks
                │
                ▼
        Package-specific rules
                │
                ▼
       PASS / FAIL / CONDITIONAL

AI’s job stops at understanding the documents.

It does not get to decide whether a claim passes.

That separation is intentional.

Extraction can be uncertain.

A scanned page is genuinely ambiguous sometimes.

A decision about a real claim shouldn’t inherit that uncertainty without a human-legible rule standing behind it.

The Final Decision

ClaimSense produces one of three outcomes.

PASS

The claim satisfies the relevant package requirements and the evidence is consistent.

FAIL

A required condition is not satisfied or the claim contains a material inconsistency.

CONDITIONAL

The system cannot cleanly establish that the claim should pass or fail without additional evidence or review.

The output is deliberately simple.

The complexity lives underneath it.

Confidence

The confidence score is not a model-generated opinion about whether the claim is correct.

It reflects the quality of the pipeline that produced the decision.

Part of it comes from extraction confidence.

Part comes from how cleanly the claim satisfied the rules.

Part comes from the quality and completeness of the documents.

The score is therefore derived from observable parts of the pipeline rather than appearing as an unexplained number from the model.

Storage

A claim is represented through three related levels of data.

Claim
  │
  ├── Documents
  │      │
  │      └── Pages
  │
  └── Decision / extracted claim data

The claim stores information about the case itself.

Documents belong to the claim.

Pages belong to documents.

Information that varies between packages — extracted fields, timeline information and fail reasons — is stored as JSONB.

Stable relationships remain structured.

Variable claim information remains flexible.

Why PostgreSQL?

The relationships in ClaimSense are naturally relational.

Claims contain documents.

Documents contain pages.

Pages produce extracted evidence.

Claims belong to packages.

Decisions refer back to the claim and the rules that produced them.

PostgreSQL represents these relationships directly.

There is no reason to force a document-processing system into a document database simply because the input happens to be documents.

Why JSONB?

Different packages require different information.

An enteric fever claim does not need exactly the same fields as a total knee replacement claim.

The extracted information also evolves as new packages are added.

JSONB gives the system flexibility without making every package change a database migration.

The principle is simple.

Stable relationships stay relational.

Variable claim content stays flexible.

Why We Didn’t Use a Vector Database

We didn’t need one.

ClaimSense isn’t searching a large collection of documents to answer a question.

Every page belongs to a known claim.

The system needs to read that page, extract what matters and use it in a deterministic pipeline.

There is no retrieval problem here.

So there are no embeddings and no vector search.

Why We Didn’t Use LangChain

The pipeline is a fixed sequence.

Classify
   ↓
Extract
   ↓
Aggregate
   ↓
Validate
   ↓
Decide

It doesn’t need an agent to decide what tool to call next.

It doesn’t need a framework to hide the sequence.

A direct call to the Anthropic SDK keeps the pipeline visible in the code.

The architecture is simple enough that the abstraction would have been more complicated than the problem.

AI’s Role

AI is intentionally limited.

ClaimSense
│
├── Identify documents
├── Understand difficult pages
├── Extract structured information
├── Preserve evidence
└── Generate claim-level understanding

Rules
│
├── Validate package requirements
├── Check completeness
├── Check consistency
├── Check timeline
└── Produce final decision

The model understands.

The rules decide.

That distinction is probably the most important architectural decision in the system.

Current Scope

ClaimSense currently supports PMJAY claim documents for the four packages built during the NHA hackathon:

• Enteric fever
• Severe anemia
• Cholecystectomy
• Total knee replacement

The system is being developed as an internal tool first.

The goal is to run it against real claim documents, find where it breaks, and add rules only when those failures teach us something useful.

The Principle

The architecture follows the problem, not the other way around.

Use rules where rules are enough.

Use AI where the documents are genuinely hard to read.

Turn pages into structured information before reasoning about the claim.

Keep the evidence behind every decision.

And don’t hand the model a responsibility the system can already meet on its own.