How to build a claims management system
The modules, architecture and integrations a claims system needs, the rules it must follow, and an order to build it in, from a clickable prototype to production.
What a claims management system does
A claims management system takes a claim from the first notice of loss to the final payment or decline. It holds the claim record, checks it against the policy, routes it to the right handler, tracks reserves and payments, and keeps the reasons for every decision.
The same shape fits property and casualty claims, health claims and warranty claims. What changes is the coverage logic, the documents involved and the rules on how fast and how fairly claims must be handled.
The modules you need
Most teams need all of these in the end. The phased plan below sets the order.
First notice of loss
Intake from web forms, email, phone and partner APIs into one claim record, with details pulled from attached documents.
Coverage check
Matches the claim to the policy in force on the loss date, its limits, excesses and exclusions.
Triage and assignment
Routes each claim by type, size and complexity, fast-tracks simple ones and sends complex ones to the right handler.
Handler workbench
One screen with the claim, documents, notes, tasks and history, so the handler does not switch between systems.
Reserves and payments
Reserves set and changed with reasons, payments within each handler's authority limit, and a second approval above it.
Documents and evidence
Photos, reports, invoices and medical records stored against the claim, with extraction and a full version history.
Fraud flags
Rules and scores that flag suspicious claims for a specialist team, without blocking honest claims.
Communication
Updates to the claimant, broker and partners by email, SMS or portal, logged on the claim.
Reporting and audit
Open claims, ageing, reserves and handling times, plus an audit trail of every change and decision.
How the parts fit together
- 01
The claim as the central record
Every module reads and writes one claim record, with an event log of what changed, when and by whom.
- 02
Rules outside the code
Routing, authority limits and coverage rules kept as versioned configuration, so a rule change is a release, not a rewrite.
- 03
Document pipeline
Upload, virus scan, storage, text extraction and classification, with low-confidence results sent to a person.
- 04
Integration layer
Adapters for the policy system, payments, partners and data providers, so a slow partner does not stall the claim.
- 05
Review queues
Work queues for handlers, approvers and specialists, fed by the rules and the event log.
- 06
Reporting store
A read copy of claim data for dashboards and regulator reports, kept off the live system.
Data model sketch
- 01
Policy and coverage
The policy version in force on the loss date, its covers, limits and excesses.
- 02
Claim and exposure
The claim, and each exposure under it (for example vehicle damage and injury), with its own status.
- 03
Party
Claimant, insured, third parties, witnesses, repairers and providers, with their roles on the claim.
- 04
Reserve and payment
Each reserve change and each payment, with amount, reason, approver and payee.
- 05
Document
File, type, extracted fields, source and version.
- 06
Task, note and decision
Who did what, and every decision with its reason and the rule version it followed.
Systems it has to talk to
- 01
Policy administration
To check cover, and to see the policy as it stood on the loss date.
- 02
Payments and banking
To pay claimants, repairers and providers, and to reconcile payments.
- 03
Document intake
Email inboxes, scanning and OCR or AI extraction services.
- 04
Partners and networks
Repairers, loss adjusters, medical providers and assistance companies.
- 05
Health claims standards
For health claims: HL7 FHIR APIs, and X12 837 and 835 transactions in the US.
- 06
Finance and fraud data
The general ledger for reserves and payments, and industry fraud databases where available.
Rules to design for
Which rules apply depends on your market and product.
- 01
Claims handling rules
Most markets set rules on fair, prompt claims handling and clear reasons for a decline, such as ICOBS 8 in the UK.
- 02
Data protection
The GDPR and local laws, with health data as a special category. Health claims in the US fall under HIPAA.
- 03
Automated decisions
If software declines or reduces a claim on its own, people may have the right to a human review. Keeping a person on the final decision avoids most of this.
- 04
AI rules
AI used for risk assessment and pricing in life and health insurance is high-risk under the EU AI Act. Claims triage needs its own check.
- 05
Audit and retention
Keep the claim file, decisions and payments for as long as local law and your regulator require.
From prototype to production
Build in this order so something real is in users' hands early.
- 01
Clickable prototype
Intake and the handler workbench for one claim type, tried by real handlers on real-looking claims before code is written.
- 02
First line in production
One product and one channel live: the claim record, coverage check, payments with authority limits and the audit trail.
- 03
More channels and automation
Email and partner intake, document extraction, fraud flags and the integrations that remove retyping.
- 04
Scale
More products and markets, reporting for the regulator, and more automation on simple claims, with a person still on the final decision.
What drives the cost
These decide most of the budget. For a number based on your own scope, use the cost tool. OceanLab bills $30-50/hr or per milestone.
- 01
Products and lines of business
Each line brings its own coverage logic, documents and partners.
- 02
Number of channels
Web, email, phone, broker and partner APIs all need intake and testing.
- 03
Legacy integrations
An old policy system without a clean API is often the largest single cost.
- 04
Document AI
Extraction from photos, invoices or medical records, and the review step around it.
- 05
Approval and authority rules
How many levels of approval, limits and exceptions there are.
- 06
Open claims migration
Moving live claims from the old system without losing history.
Product builds that match this guide
Kittiwake - AI Claims Intake with a Person Behind Every Decision
Designed and built a clickable claims intake console for a UK motor and home insurer: AI reads the customer's story and photos, extracts the facts, drafts a damage estimate and suggests a triage route with its reasons, while a named person confirms cover, routes the claim and makes every call that could go against the customer.
Qistas - Health Claims Adjudication with an Explanation on Every Line
Designed and built a clickable claims adjudication platform for a Saudi cooperative health insurer: claims arrive through NPHIES, from member reimbursements or on paper, a rules engine decides each line with a trace and a provider explanation in Arabic and English, and only uncertain lines reach a medical reviewer.
Headgate - FHIR Interoperability API Platform for Claims, Clinical Data and Prior Authorization
Designed and built a clickable console for the FHIR APIs a US regional health plan must run under federal interoperability rules: API health across Patient Access, Provider Directory, Formulary, Provider Access, Payer-to-Payer and Prior Authorization, a security review queue for third-party apps, and one clock for every prior authorization request, however it arrived.
Sotdae - Travel Insurance Claims Agent with Human Decisions and Cited Clauses
Designed and built a clickable claims processing agent for a Seoul travel insurance agency: it takes claims in by chat or email, reads receipts and medical reports, checks cover against the policy wording in force on the travel date and writes a recommended decision with the clauses it relied on, while adjusters approve every payment and only people with decline authority can decline.
Two ways to work with OceanLab
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
Questions
Should we build or buy a claims system?
Buy when your products are standard and a vendor fits them well. Build, or build on top of what you have, when your products, channels or rules are unusual, or when claims handling is how you compete.
Can AI handle claims on its own?
It can read documents, fill the claim record and suggest a route or outcome. Keeping a person on the decision keeps it explainable and avoids most automated-decision rules.
Do we need to replace our policy admin system first?
No. A claims system can read cover from the existing policy system through an integration layer, and the two can be modernised separately.
