Insurance contracts CSV import API
insurance_contracts_v1
Import this template via API. Import payer and insurance contract metadata from CSV into a FHIR Coverage-shaped row.
30-second curl
curl -X POST https://api.adaptivmapr.com/v1/uploads \ -H "Authorization: Bearer $ADAPTIVMAPR_API_KEY" \ -F "template=insurance_contracts_v1" \ -F "file=@your_data.csv"
At a glance
- Pack
- Healthcare
- FHIR resource
- Coverage
- Risk level
- low
- Fields
- 4 (1 required, 0 validated)
Why this template?
The Insurance contracts template captures the payer-side metadata for a clinic's contracts: which insurer, what type of cover (KVG, VVG, LaMal, LCA in the Swiss canon), and the validity window. Each row emits a FHIR Coverage resource. It is `low` risk because the row does not name an insured person — that link belongs in a separate enrollment table. Customers import this template when standing up a billing module, when migrating between practice-management systems, or when consolidating after an acquisition. The validity window (valid_from / valid_until) is auto-parsed across DE / FR / IT / EN date formats; the contract_type enum is Swiss-shaped because the original buyer set was Swiss, but it is the easiest field to fork and extend with US / EU / UK payer types.
No identifier validation on `payer` because insurer names are unstable — they merge, rebrand, and acronymise. Customers usually post-process the column against an internal lookup table. The template guarantees the column exists and is non-empty; cleaning it up is downstream work.
Migration scenarios & common foreign headers
Migration scenarios for Insurance contracts: standing up a brand-new billing module that needs the full payer matrix on day one, consolidating after a clinic-group acquisition where two practice-management systems each carry their own contract metadata, migrating from a legacy billing system with a fresh contract list, and annual contract refreshes when payer offerings change in January. Foreign headers we routinely see: "Versicherer / Assureur / Asegurador / Assicuratore / Vertragstyp / Type de contrat / Tipo de contrato / Gültig von / Valable du / Válido desde / Gültig bis / Valable jusqu'au / Válido hasta". The cascade absorbs the variation across the four Swiss official languages without an LLM call — Swiss healthcare ingestion is the original target buyer for this template.
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 |
|---|---|---|---|---|
| payer | string | yes | — | versicherer · assureur · asegurador |
| contract_type | enum | — | — | vertrag · contrat · contrato |
| valid_from | date | — | — | — |
| valid_until | date | — | — | — |
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=insurance_contracts_v1" \ -F "file=@your_data.csv"
The canonical template definition is read-only at GET /v1/templates/insurance_contracts_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: "insurance_contracts_v1",
headers: ["payer", "contract_type", "valid_from", "valid_until"]
})MCP install instructions →FAQ — Insurance contracts CSV import
Can I extend contract_type beyond Swiss values?
Yes — fork the template and add US / EU / UK options (Medicare, Medicaid, HMO, PPO, NHS, etc.). The canonical version stays CH-shaped because that is the original buyer set; extension is the standard pattern.
How do I link a contract to a patient?
That linkage belongs in a Coverage.beneficiary or an enrollment table. The contracts template is payer-side metadata only — the per-patient link is a separate import.
What about open-ended contracts (no valid_until)?
Leave valid_until null. The validator only enforces the date format when a value is present.
Why does the template not capture insurance product tiers?
Product tiers are payer-internal taxonomy and rarely portable across payers. Fork the template and add a `tier` enum if your downstream needs it; the canonical row stays at the contract-shape level.