How do you stop re-keying claims into your claims system?
Take claims in as data: your claims system's API or import, an intake portal, or an electronic feed. If a person still reads each document, a document-reading tool can turn it into data. Only then automate the remaining screen entry, and check each save against the claims system's own data. Re-keying into carrier portals is a separate, harder problem.
Updated 2026-10-14
The options, in order
| Option | Good when | Watch out for |
|---|---|---|
| Your claims system's API or bulk import | Claims already arrive as files or forms | Mapping each source's fields once |
| An intake portal or electronic feed | You can ask claimants or providers to submit online | Not everyone will |
| A document-reading tool | Claims arrive as PDFs or paper | It reads; something still has to enter and check |
| Screen entry by a program, with a read-back | The system has no usable import for this claim type | It needs a read-only way to confirm the save |
If you enter through the screen
In our openIMIS test, a program learned from a demonstration entered 6 synthetic claims: 5 were saved and read back by our test setup, 15 of 15 fields matching, and the one with a mistyped member number stopped before saving. It wasn't faster per claim than a test script typing at a person's pace (42.3 seconds); a person just no longer types. We found no published study of how long insurer staff take per claim, so time your own.
- Confirm each save through a read-only database role, a report or an API.
- Make sure a mismatch, such as no member found, stops before saving.
- Know the limits: a number that belongs to another member can look normal on screen; only a record check or a person catches it.
For agencies re-keying into carrier portals
Agencies often key one submission into several carrier portals; in one vendor's 2026 survey, 74% of independent agents ranked re-keying as their top pain. The options are comparative raters, carrier downloads (IVANS in the US, CSIO in Canada), and carrier APIs where offered. Screen entry into a carrier portal can't be checked the same day, and portal terms often forbid letting anyone else use your login. OpenAdapt hasn't run on a carrier portal, and we don't offer it yet.
Where OpenAdapt fits
For carriers, MGAs and TPAs entering claims into their own system: see claims intake and Insurance. API or screen automation?
Sources
- OpenAdapt on openIMIS 25.10 (open-source insurance system), local test copy, 12 Oct 2026. A program learned from one demonstration entered 6 synthetic health-facility claims in one batch, with 0 AI model calls. 5 were saved; our test setup read each back through SQL and the openIMIS API, and 15 of 15 fields matched the claim document. On the 6th, the insured number had two digits swapped: openIMIS found no member, the screen no longer matched the demonstration, and the program stopped before saving (no claim was written). The engine labels the 5 saved runs "Finished, not checked", because this program has no record check of its own yet.
- Same test copy, 12 Oct 2026: a test script typed one claim at a person's pace (about 39 words a minute, with 1 to 2.6 s pauses to read the document): 42.3 s from start to the Save click. A test script, not a person, and signed in with the blank form already open.
- Ivans, 2026 independent agent survey (vendor industry survey, 700+ agents): 74% rank re-keying into carrier portals as their top pain.
See it on your process
Bring one task your team types every day. We'll tell you whether it fits, and what a test on your own system would cover.