The Claim Loop

ClaimPod does not receive claims. It receives the ingredients your practices already produce, and builds claims from them. The loop below is the whole product in one page.

flowchart TD
  A[Files arrive] --> B[Patients and visits]
  B --> C[Claim generated]
  C --> D[Ready to file]
  D --> E[Filed as 837P or CMS-1500]
  E --> G[Clearinghouse and payer acknowledge]
  G --> F[Payment posted]

  A <-. a row ClaimPod cannot resolve .-> R1(["Import review"])
  B <-. a charge missing a code .-> R5(["Coding review"])
  C <-. findings to clear .-> R2(["Claim review"])
  G <-. a rejection or no answer .-> R4(["Follow-up claims"])
  F <-. a payment that does not fit .-> R3(["Remittance review"])

  classDef human stroke-width:3px;
  class R1,R2,R3,R4,R5 human;

The rounded boxes are where a person is asked for something along the way. Everything else runs whether you are watching or not, and the sections below say what each stage does.

Data Arrives and Is Staged

Files land from a folder, an SFTP drop or a bucket, and a mapping template translates each file shape into patients, visits and services. Rows are staged and validated before anything reaches your live data. Clean rows flow straight through.

Problem Rows Stop

A row ClaimPod cannot resolve on its own becomes a work item rather than a silent failure or a bad record. Ambiguous patient identity, a conflicting field, a code it does not recognise: these wait for a person, and only that person’s decision lets the row through. An import sent to Coding Review is the exception for codes: an unknown or missing code lets the row through, and the visit waits in Coding Review until a coder releases it.

A row whose only problem is a service with no price on file flows through too, because nothing about the service itself is in doubt, and still gets a work item asking for the charge. The visit waits for that charge before it can become a claim.

Claims Are Generated From Visits

Once a visit has what a claim needs, ClaimPod builds the claim from it, so a claim says what the visit said. You can still add a claim by hand with Create, and the automatic rebuilds keep the lines you edited or added on a draft.

Rules Check Every Claim

Generated claims are checked against the client’s review rules. Claims that pass promote themselves to Ready without anyone opening them. Claims that fail arrive as work items with each finding painted on the exact field at fault.

This is the ratio the product exists to change: a billing operation that reviews every charge by hand, to one that reviews only what a rule stopped. When a review rule changes, every Draft and Ready claim is checked again against it.

Ready Claims Are Filed

Ready claims collect into export batches: an 837P file with proper control numbers for electronic payers, printed CMS-1500 forms for paper ones. Batches never change after the fact. A retry is a new batch, so the history stays honest about what was sent and when.

The Clearinghouse Answers

Before any money moves, the clearinghouse and the payer acknowledge the file and each claim in it with a 999, TA1 or 277CA. An acceptance moves the claim to Accepted. A rejection moves it to Rejected, and it waits in Follow-up Claims to be corrected and resent, as does a claim the payer has not answered in time.

Remittances Come Back and Post

When the payer’s remittance arrives, clean payments post automatically. Anything anomalous is held for a person instead of quietly booking money against the wrong claim.

Related: Claims · Import Batches · Work Queues