OpenAdaptClaims intake, without re-keying each claim
OpenAdapt enters each claim into your claims system as a program learned from a demonstration. By default each save waits for approval, and it stops when the screen doesn't match. On openIMIS, an open-source insurance system, it saved 5 of 6 synthetic claims (15 of 15 fields read back by our test setup) and stopped before saving 1.
Updated 2026-10-18
Today
A claims clerk reads each claim document and keys it into the claims system:
- Type the insured number and wait for the member lookup.
- Type the claim number.
- Search for and pick the main diagnosis.
- Type the explanation.
- Add the service; the system fills the price from its tariff.
- Save.
In our test, a test script typing at a person's pace took 42.3 seconds from start to the Save click, with the form already open. That's a script, not a person, and we found no published study of how long insurer staff take to key a claim. We time your team's own work in the access check, so the estimate uses your minutes, not ours.
With OpenAdapt
- A staff member enters one claim while OpenAdapt records it. (In our test, a test script did the demonstration.)
- OpenAdapt turns it into a program with 4 values to fill: insured number, claim number, diagnosis search text and explanation.
- Each new claim runs through the same steps; a batch runs as a worklist, once per claim. Each save waits for approval.
- If the screen doesn't match the demonstration, such as no member found for the insured number, it stops before saving and leaves the claim for a person.
In the 12 Oct test, OpenAdapt took 47 to 73 seconds a claim on a shared test machine running openIMIS under emulation, against 42.3 seconds for the test script.
What's been tested
| Run | Result | How it was checked |
|---|---|---|
| 6 synthetic claims in one worklist run, 12 Oct 2026 | 5 saved; 1 stopped before saving (mistyped insured number) | Our test setup read each claim back through SQL and the openIMIS API: 15 of 15 fields matched. The program has no record check of its own yet, so the engine labels the saved claims "Finished, not checked". |
| 3 runs, one claim each, July 2026 | 3 of 3 Done and checked | A direct database read: exactly one claim, status Entered, on the right member; 0 duplicates. |
The 15 fields: claim number, insured number, member's names, facility, diagnosis code, visit date, date claimed, explanation, service, quantity, price, total claimed, claim administrator and status.
The limits
- Each claim shape is its own program. The one measured here enters a single service with no attachment, for a member's first visit.
- A member with an earlier claim sees a different screen, so the program stops for them: an extra stop, not a wrong entry.
- A mistyped number that belongs to another member looks normal on screen; the record check or a person catches it.
- The program picks the first diagnosis that matches the search text, so the search text needs to be exact.
Is it a fit?
- The claim details reach you as data (a file, an email form or an intake system), or as a PDF, image or email. OpenAdapt can read those documents and holds back any unclear field for a person. Paper has to be scanned first.
- Your claims system offers a second way to read a saved claim: a read-only database role, a report or an API.
- The claims follow a few repeating shapes. Each shape is its own program.
- Your system runs in a browser, an installed program or remote desktop.
Questions
Does it work with our claims system?
It works through the screen, wherever your staff key claims. Our measured claims runs are on openIMIS, an open-source system, with synthetic records. We qualify each workflow on your own system before it touches a real claim.
Why not use the system's import or API?
If your claims system takes claims through an import or an API, use it. See How do you stop re-keying claims?.
What does it cost?
Free to run locally. Team $499 a month. Healthcare and enterprise qualification sprints from $15k. Pricing.
Related: coverage look-ups · how the stops work · Your agent alone, or with OpenAdapt · Security
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.
- OpenAdapt engine time per saved claim in the 12 Oct 2026 batch: 47.0 to 72.7 s, on a shared machine running openIMIS under emulation. OpenAdapt was not faster than the test script per claim.
- OpenAdapt on openIMIS 25.10, July 2026: one health-facility claim per run, 3 of 3 checked by a direct database read (exactly one claim, status Entered, right member), 0 duplicates, 25.6 to 30.3 s a run, 0 AI model calls.
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.