Claims line items CSV import API
claims_line_items_v1
Import this template via API. Import healthcare claim line items from CSV with CPT and ICD-10 code validation. FHIR Claim.item-shaped.
30-second curl
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=claims_line_items_v1" \ -F "file=@your_data.csv"
At a glance
- Pack
- Healthcare
- FHIR resource
- Claim.item
- Risk level
- medium
- Fields
- 4 (2 required, 2 validated)
Why this template?
The Claims line items template is the schema for billing claim detail — each row is one procedure performed for one patient on one day, priced and coded. The template is `medium` risk because it indirectly carries PHI (a CPT code tied to a service date and a patient id is identifying), so full-data mode is gated behind the phi-cloud bundle. CPT codes are validated against the 5-digit shape; ICD-10-CM codes against the A00 / A00.0 pattern; amounts against locale-aware number parsing. The template emits as FHIR Claim.item, which is the standard cross-border representation for billing detail. Customers use it when porting between practice-management systems, when feeding a clearinghouse, or when building an internal denial-analysis pipeline. The cascade picks up multilingual variants (Leistungsdatum, date du service, fecha del servicio) without an LLM call.
The amount field is currency-agnostic — claims systems usually run single-currency per workspace, so there is no currency column in the canonical shape. Service_date is required and parsed across the same date formats as the rest of the catalogue. CPT codes resolve via the same fallback resolver as LOINC and ATC; a "99213" stays a "99213" but a "office visit established 15min" resolves to "99213" when confidence is high enough.
Migration scenarios & common foreign headers
Migration scenarios for Claims line items: feeding a clearinghouse with a freshly extracted batch, building an internal denial-analysis pipeline that runs on a year of historical line items, porting between practice-management systems where the line-item shape differs subtly, and reconciling payer remittance advices against billed lines. Foreign headers we see in the field: "CPT / Code CPT / Code de procédure / Codigo CPT / ICD / ICD-10 / Diagnose / Diagnostic / Diagnóstico / Betrag / Montant / Importe / Importo / Leistungsdatum / Date du service / Fecha del servicio / Data del servizio". Because billing files are the most regulated CSV input in healthcare, validator coverage matters more here than anywhere else — both CPT and ICD-10 run through canonical-format validators with resolver fallback for free-text descriptions.
Schema
The canonical column set, with the type each row carries, whether it is required, the field-level validators that fire on commit, and the multilingual header hints the cascade resolves against.
| Column | Type | Required | Validators | Hints |
|---|---|---|---|---|
| cpt_code | string | yes | cpt_code | cpt · procedure |
| icd10_code | string | — | icd10_code | icd · icd-10 · diagnose |
| amount | number | yes | — | betrag · montant · importe · amount |
| service_date | date | — | — | leistungsdatum · date du service · fecha del servicio |
How AdaptivMapr maps your headers to this template
Five layers run in order, cheapest first. Layer 1 (Statistics) auto-accepts headers that have been mapped the same way across past uploads. Layer 2 (Heuristic) compares your header to the column name, the optional label, and every registered hint (DE / FR / IT / EN / ES) after a Unicode-and-punctuation-normalising pass. Layer 3 (Fuzzy) catches typos and reordered words. Layer 4 (Semantic) uses cached embeddings to catch the long tail of paraphrases. Layer 5 (LLM) only fires on genuinely ambiguous columns, constrained to the template’s allowed column set so it cannot invent a field. When a layer auto-accepts, the lower-cost layers below it never run — that is the cost lever.
REST · POST /v1/uploads
Pass the template_id; the cascade picks up the rest.
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=claims_line_items_v1" \ -F "file=@your_data.csv"
The canonical template definition is read-only at GET /v1/templates/claims_line_items_v1.
MCP · Cursor / Claude Desktop
Drop AdaptivMapr into your IDE. Schema-only calls are free and unlimited.
// In Cursor or Claude Desktop with the AdaptivMapr MCP server installed:
adaptivmapr.match_headers({
template: "claims_line_items_v1",
headers: ["cpt_code", "icd10_code", "amount", "service_date"]
})MCP install instructions →FAQ — Claims line items CSV import
Is HCPCS Level II supported alongside CPT?
CPT codes follow the 5-digit pattern; HCPCS Level II is a letter + 4 digits. Add a HCPCS field via a fork — the canonical template is CPT-only because that is the common case.
Does AdaptivMapr validate the modifier suffix?
Modifiers are not in the canonical row. Add them as a separate field if your downstream needs them; the cascade is shape-agnostic.
Why no place_of_service code?
Place of service is per-encounter, not per-line-item — model it on the parent claim. Add it here via a fork if your downstream expects it.
How is the ICD-10 dot handled?
Both A00 and A00.0 forms validate. The validator does not normalise; round-tripping preserves the source representation.