Extract data from CMS-1500 claim forms
The CMS-1500 is the paper claim a physician practice sends to a payer, and a billing office reads them constantly, whether scanned from a clearinghouse rejection or received from an out-of-network provider. Maintained by the NUCC, the form packs an entire claim into numbered boxes: the patient and insured in Boxes 1 through 11, the diagnosis pointers in Box 21 (ICD-10 codes), the rendering and billing provider identifiers including the NPI in Boxes 24J, 32, and 33, and the service lines in Box 24 where each row carries a date of service, a place-of-service code, a CPT or HCPCS procedure code with modifiers, a diagnosis pointer, a charge, and units.
Difficulty lives in the Box 24 service-line grid and the linkage between diagnoses and procedures. Each of the six service lines points back to one or more of the Box 21 diagnosis codes by letter (A, B, C), so the clinical justification for a procedure has to be reconstructed from the pointer rather than the code itself. Modifiers on a CPT code (such as 25 or 59) change reimbursement and must stay attached to their procedure. Rendering provider NPIs in 24J can differ from the billing NPI in Box 33. Scanned forms skew and the tight grid shifts, so a charge can drift into the wrong column.
Talonic reads the CMS-1500 by box number and returns the patient, insured, the Box 21 diagnosis list, and the Box 24 service lines with their procedure codes, modifiers, diagnosis pointers, charges, and provider NPIs. A billing team posts and scrubs claims from structured data rather than re-keying a dense grid.
What gets extracted from CMS-1500 claim forms
How extraction works for CMS-1500 claim forms
CMS-1500 forms reach a biller as clearinghouse PDFs, payer rejections, and scanned paper, and the NUCC layout is fixed enough to anchor on box numbers rather than pixels. Talonic reads the claim against the CMS-1500 box map in the Field Registry, which binds each value to its numbered box so a skewed scan does not drift a charge into the wrong column. Box 24 service lines are captured as a structured array, and each line keeps its CPT or HCPCS procedure code, its modifiers, its diagnosis pointer back to the Box 21 ICD-10 list, its charge, and its units. Rendering NPI in Box 24J and billing NPI in Box 33 are kept distinct. Every value returns with a confidence score and pixel-region provenance under DIN SPEC 91491 conformity, so a billing team can verify a service line against the source claim before submitting.
Sample extraction
A scanned CMS-1500 with two service lines
{
"patient_name": "Helen Park",
"insured_id": "AET558210934",
"payer_name": "Aetna",
"diagnosis_codes": [
"I10",
"E11.9"
],
"service_lines": [
{
"date_of_service": "2026-04-18",
"place_of_service": "11",
"procedure_code": "99214",
"modifiers": [
"25"
],
"diagnosis_pointer": "A",
"charge": 320,
"units": 1,
"rendering_npi": "1396744321"
}
],
"billing_provider_npi": "1487553210",
"total_charge": 320
}Frequently asked
Does it preserve the diagnosis-to-procedure linkage?
Each Box 24 service line keeps its diagnosis pointer (A, B, C) back to the Box 21 ICD-10 list, so the clinical justification for each procedure is reconstructed rather than lost, which is what a payer scrubs for.
Are CPT modifiers captured per line?
Modifiers such as 25 or 59 stay attached to their procedure code on the service line, because they change reimbursement and a claim posted without them will pay incorrectly.
Does it distinguish the rendering and billing NPIs?
Rendering and billing provider NPIs (Box 24J and Box 33) are returned as separate fields, since they frequently differ within a group practice.
What fields are extracted from CMS-1500 claim forms?
Talonic returns CMS-1500 claim forms as schema-validated, typed fields. Common fields include Patient Name, Insured ID, Payer, Diagnosis Codes (Box 21), and more, each normalized (dates to ISO 8601, amounts as numbers) and mapped to a stable key so the output shape stays the same across layouts.
How accurate is extraction from CMS-1500 claim forms, and how is confidence reported?
Every extracted cell carries a confidence score from 0.0 to 1.0 and a provenance pointer back to the source page and region, so low-confidence values can be reviewed against the original before the data is trusted downstream. There is no single accuracy number: confidence is reported per field so you can gate on it.
Can I use CMS-1500 claim forms extraction in production?
Yes. The same engine behind this guide is available as a production REST API and Node SDK with sync, async, and streaming modes, schema versioning, signed webhooks, and EU-resident processing. Start free with an API key, then scale on usage-based pricing.
What does it cost to extract data from CMS-1500 claim forms?
There is a free tier for prototyping and agent evaluation with no credit card. Paid usage is credit-based at 1,000 credits per euro: page ingestion is 100 credits per page and registry-resolved queries are free. See talonic.com/pricing for current rates.
Ready to extract from your own CMS-1500 claim forms?
Author note
Reviewed by Talonic engineering, schema review · last reviewed 2026-06-14