Guides

Read the payers' remittances (835) as JSON, with every payment matched to its claim and every adjustment in plain words; match what could not be matched, and post them when your system has.

When a payer pays, it sends an electronic remittance advice, an 835 file: what it paid on each claim and line, and why it adjusted the rest. Claim House collects those files, turns each remittance into an ERA you read as JSON, matches every payment to the claim it answers, and moves the claim to paid or denied. Your system then posts the payments without anyone reading an 835, and tells Claim House it did.

With a test key, the sandbox sends remittances for the claims whose scenario has one: CH-PAID-ERA (paid in part), CH-DENIED (denied), and any claim to the test payer CHTEST (paid in full), 2 minutes after the payer accepts the claim. In live mode no remittance arrives until the dental network is connected. An ERA is a document of your whole organization (it can pay claims made by any of your keys and people): a key needs read permission to read ERAs, and both read and submit to post one or match a payment. A key with submit only can reconcile the claims it made.

How it works#

1. The payer pays (an EFT or a check) and sends its 835. Claim House stores it (with every bank and account number cut to its last four characters), reads it, and makes one ERA for each remittance in it: one payer, one payment, one of your offices as the payee.
2. Each claim payment is matched to your claim: by the patient control number the payer echoes (CLP01, which is the claim's patient_control_number), else by the payer's claim number when exactly one of your claims to that payer has it. A payment from a payer that is not the claim's, or for a claim that cannot take a payment in its state (one being corrected, say), is left unmatched with its unmatched_reason. Each line is matched by its line control number, else by procedure code, service date and charge when exactly one line fits. Nothing is matched by guessing: a payment that does not fit one claim with certainty stays unmatched for you to match by hand.
3. A matched payment moves its claim: paid (with what was paid, allowed and owed by the patient), or denied. You get era.received for the ERA and claim.paid or claim.denied for each claim (see Events and webhooks).
4. You post the payments in your system, then post the ERA: its claims become reconciled. Or reconcile claims one at a time.

Read your ERAs#

GET /eras lists them, newest first. Filter by state (needs_review until you post it, then posted), payer_id, or the payment date (paid_from, paid_to):

curl "https://sandbox.myclaimhouse.com/api/v1/eras?state=needs_review&limit=10" -H "Authorization: Bearer $CLAIMHOUSE_KEY"

GET /eras/{id} shows one: the payment (method, trace number, date and total), whether it adds up (balanced), and each claim payment with its lines:

curl "https://sandbox.myclaimhouse.com/api/v1/eras/$ERA_ID" -H "Authorization: Bearer $CLAIMHOUSE_KEY"

Money is a decimal string with two places ("820.80"), so nothing is rounded on the way. The trace number is the one on the deposit in your bank account. A claim payment has:

• claim_id, and match: matched, manual (matched by hand) or unmatched (claim_id is null, and patient_name shows the patient as the payer wrote it, to find the claim; it is null once matched). unmatched_reason says why a payment naming one of your claims was not applied: payer_differs (the ERA's payer is not the claim's), claim_not_payable (the claim could not take a payment in its state: one being corrected, voided, or a predetermination with a void open), estimate_for_claim (an estimate naming a claim) or payment_for_predetermination (a payment naming a predetermination).
• outcome: paid, denied, reversal (the payer took an earlier payment back), estimate (the answer to a predetermination, never a payment) or status (the payer reported on the claim without paying or denying it).
• charge, paid, allowed, patient_responsibility, and adjustments, each with its group, reason code and amount, and the group and reason in plain words.
• lines, each with its own figures, adjustments, remark codes and the claim line it pays (claim_line_number).

The payer's status codes (status.code) in plain words:

Adjustments in plain words#

Every amount the payer did not pay is an adjustment: a group (who carries it) and a reason code (why). The group:

The common reason codes, in our own words (any other code is shown as the code itself):

In the sandbox's CH-PAID-ERA, a crown charged at 1140.00 is allowed 1026.00 and paid 820.80: 114.00 is a contractual adjustment (CO 45), and 205.20 is the patient's coinsurance (PR 2), which is what the patient owes.

Match a payment by hand#

A payment Claim House could not match with certainty is unmatched: the patient control number it echoes is not one of yours, or it names a claim of nobody you know. Find the claim from the patient's name and the figures, then match it:

curl "https://sandbox.myclaimhouse.com/api/v1/eras/$ERA_ID/claims/$ERA_CLAIM_ID/match" \
  -H "Authorization: Bearer $CLAIMHOUSE_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "claim_id": "clm_..." }'

The payment is applied to the claim as if it had matched on arrival. The claim must be yours, in the key's mode, and able to take it (sent, and not being corrected); it can be a claim to any payer of yours. When the ERA's payer is known and is not the claim's (an unmatched_reason of payer_differs, say), send "confirm_payer": true to say you meant it; without it the match is refused with 422 naming confirm_payer. A payment matched already is refused with 409 CONFLICT. Two payments of one ERA can go to one claim (a reversal and its correction, say).

Post#

When your system has posted the payments of an ERA, post it: every claim it paid or denied becomes reconciled, and the ERA posted. Posting it again changes nothing. An ERA with nothing to post (only unmatched payments, estimates or statuses) can be posted too, to mark it reviewed; its unmatched payments can still be matched afterwards. Before you post, postable_count on the ERA says how many claims posting marks reconciled, and postable on each claim payment says whether its claim is one of them.

curl "https://sandbox.myclaimhouse.com/api/v1/eras/$ERA_ID/post" \
  -H "Authorization: Bearer $CLAIMHOUSE_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{}'

To reconcile one claim (a payment you posted on its own, or one you matched by hand after posting the ERA), use POST /claims/{id}/reconcile. A claim's payment is also on the claim itself: payment on GET /claims/{id} has the ERA, the figures and when you reconciled it.

When the payer changes its mind#

• Paid is the sum; allowed and the outcome are the current payment's. A claim's payment.paid and payment.patient_responsibility are the sums of every payment applied to it: a reversal and its corrected payment net out whatever order they come in, in one remittance or in files delivered out of order. A second payment with no reversal adds to the first. payment.allowed and payment.outcome (paid or denied) are those of the claim's current payment: the latest one, by payment date, that no reversal took back (a reversal cancels the earliest payment it negates). When that cannot be told with certainty (two payments of the same dates), allowed is null, and the claim is paid when something is paid, else the outcome those payments agree on, else denied. When the sums are zero and the payer sent as many reversals as payments, nothing stands, whether or not each reversal names its payment exactly. The claim's timeline keeps every figure. You get claim.paid (or claim.denied) for each payment that leaves the claim paid (or denied). A reconciled claim becomes paid (or denied) again, and its timeline says to post the new figures.
• A reversal. When the payer takes a payment back (status 22, with negative amounts), it is subtracted: when nothing stays paid, the claim goes back to accepted_payer, its payment is cleared (the timeline keeps it), and you get claim.payment_reversed. A reversal for a claim you voided after it was paid is recorded on the voided claim (its figures cleared, its state unchanged). If it was reconciled, undo the posting in your system. A reversal of a payment that has not arrived yet moves nothing (its timeline entry says so, and there is no claim.payment_reversed): it counts against that payment when it arrives.
• A denial you can fix. Correct a denied claim (or a paid one, or one the payer accepted) with POST /claims/{id}/resubmit: it goes to the payer again as a replacement that names its payer claim number, under the same claim ID, with its attachments. See Claims.

What is checked#

• It adds up. The payment total must be the claim payments less the provider-level adjustments (a recoupment, a forward balance), each claim's charge less its payment must be its adjustments, and the patient responsibility must be the patient's adjustments. An ERA that does not add up is kept and shown with balanced: false and its findings: the claims that add up on their own are applied, the others are not (their timeline says so). Review it before you post it. A claim payment that does not add up is never applied, by match or by hand: take it up with the payer, and record what it paid in your system.
• Whose it is. A remittance belongs to the organization whose office it was paid to, by the office's NPI and tax ID. A remittance that names an office of nobody, or offices of more than one organization, is held for Claim House staff and shown to no organization. A file of remittances is yours to read (in Batches & files) only when every remittance in it was applied to your organization.
• Once. The same remittance delivered twice, in one file or another, is applied once: each claim is paid once, and the file says how many it had received already. Two remittances are the same when their trace number, payer, payee NPI and tax ID (written with or without a dash) and every money-bearing fact match (the payment, and each claim's and line's figures and adjustments); wording, names and file dates do not count. A remittance with the trace number, payer and payee of one applied already but other figures is held for Claim House staff, never applied twice or dropped.
• A remittance that cannot be read. Inside a remittance, a segment that is not an 835 segment with an element of five digits or more (text in other delimiters, a payer's own segment with a date, say; two short numbers are only a note) holds that remittance for Claim House staff, for good (a file read again never applies it); the other remittances of the file are applied, and the file is then no organization's to read, as any file with a held remittance.
• A file that cannot be read. An 835 with text outside its transaction sets, or a second interchange, is not read at all: it is quarantined at once with every run of five or more digits masked, nothing in it is applied, and it stays with the network for Claim House staff to recover.
• Your own file only. GET /eras/{id}/x12 returns the remittance as text, one segment per line: your remittance only, as an interchange of its own (a file that also held other organizations' remittances is never shown), with bank and account numbers cut to their last four characters.

curl "https://sandbox.myclaimhouse.com/api/v1/eras/era_00000000000000000000000000/x12" -H "Authorization: Bearer $CLAIMHOUSE_KEY"

Each ERA received is one usage record (eras); a test one is never billed, and neither is an ERA that carries only estimates (the predetermination was billed when it was sent).