What insurance OCR returns, and what your claims system needs
Your OCR already returns the text. We build the part that returns fields, and the build is free.
Insurance OCR returns the characters on a document and where they sat on the page. A claims system needs named fields with values, checked against each other and against the claim. Covering that distance is the work: identifying what the document is, reading fields by what they are, and flagging whatever cannot be settled.
Fabrx builds the API. Landing it in a given system is done by partners, so the only requirement is a system that accepts an API call.
What moves, and what it becomes
First notice of loss
Arrives by email, portal and phone transcript on the same day, in whatever shape the sender used. The date and time of loss is the field that decides coverage and the field most often buried in a sentence.
A claim record with loss date, cause, location and reporting party
Your claims system
Insurance cards and member IDs
Usually a phone photograph, often at an angle, often of a card that has been in a wallet for two years. Group number and plan code sit in different places on every issuer.
A verified member record with carrier, policy and group numbers
Your claims system
Loss runs
Every carrier formats these differently and the useful part is a table that runs across pages. Open reserves and paid amounts are what the reader wants, and they are the columns that break when a table is split.
A claims history with dates, status, paid and reserved amounts
Your claims system
Medical records and bills
Long, mixed, and often a scan of a print of a fax. Billed amounts and dates of service matter, and they sit among pages that do not.
Line items with service dates, codes and amounts, linked to the claim
Your claims system
Certificates of insurance
ACORD forms when you are lucky, and a carrier variant when you are not. Limits, coverage type and expiry dates are the fields a compliance check runs on.
A compliance record with carrier, limits, coverage and expiry dates
Your claims system
Policy documents and endorsements
The endorsement is what changed the policy, and it usually arrives separately from the policy it changed. Effective dates are what tie the two together.
Policy terms with effective dates and the endorsements against them
Your claims system
What happens to one document
Your documents
A document arrives. Your documents
A claims inbox, a broker portal, a shared drive, or a phone camera in the field.
T+0
Fabrx
Identify what it is. Fabrx
We identify what each document is before anything is read, so a loss run and a medical bill are not treated as the same document.
If Document type not recognised
Hold for review. Fabrx. Needs a person.
A named person on your side sees the document, the field in question and what the extraction read, before anything reaches the claim.
needs a person
Then it rejoins the path above.
Read the fields. Fabrx
Fields are read by what they are, wherever they sit, so a carrier redesigning its form does not need a rebuild.
Check what can be checked. Fabrx
Dates that have to fall in order, totals that have to agree with their line items, a policy number that has to match the claim it arrived against.
If A check did not pass
Hold for review. Fabrx. Needs a person.
A named person on your side sees the document, the field in question and what the extraction read, before anything reaches the claim.
needs a person
Then it rejoins the path above.
Send the payload. Fabrx
A structured record, the same shape every time, posted to an endpoint you own or written into your claims system directly.
Where we hand over
The handoff is a JSON payload to an HTTPS endpoint you own, or a call into your claims system against an access you authorise and can revoke. Which one it is gets settled on the call.
Your claims system
Fields on the claim. Your claims system
Your claims system, your rules and your adjusters, all running exactly as they do today.
What we do, and what stays yours
Fabrx builds and runs
- Reading the document, whatever shape it arrives in
- Identifying what each document is before it is read
- Pulling the fields a claims record needs, and checking the ones that can be checked
- Flagging anything that needs a person, with the document attached
- Delivering a payload to an endpoint you nominate
- Rebuilding the extraction when the fields you need change
You keep
- Whether the claim is covered, what it reserves, and whether it pays
- Your claims system, its rules and its permissions
- The call that writes the payload, run by you or your partner
- Naming the document types to expect, which is what we look for
- Somebody to look at the output and tell us whether it is right
When a document is wrong
A pipeline with no failure path is a diagram of a good day. These are the ones that happen.
The scan is unreadable
The document stops before extraction and is never guessed at. A fax of a photocopy reaches a point where the characters are not recoverable, and we say so.
Who sees it. Whoever sent it, by reply, with the page that failed.
- Rescanned and reprocessed
- Keyed by hand, the way it is handled today
A field contradicts another field
A date of loss after the date of report, or a total that does not agree with its line items. The document is read, and the pair that disagrees is held before anything reaches the claim.
Who sees it. The claims handler who owns the file, with both values shown.
- Confirmed or corrected by a person
- Queried with the sender
One PDF holds several different documents
A single attachment regularly carries a bill, a report and a letter. The bundle is split and each part is identified on its own before any of it is read.
Who sees it. Nobody, while the parts are recognised. Anything unrecognised goes to review.
- Each document processed separately
- The unrecognised part held for a person
The document is not what the covering email says it is
Classification happens before extraction, so a policy document sent as a loss run is identified as a policy document. It is set aside and reported instead of being read against the wrong set of fields.
Who sees it. The claims handler, with what we identified and what was expected.
- Routed to the right process
- Returned to the sender
Insurance OCR, and the three other ways this gets done
The same document, four approaches, and what each one asks of you.
What you get back
By hand
Fields, typed by a person who read the document.
Template OCR
Text, and its position on the page. Turning that into fields is yours to build.
Outsourced processing
Fields, typed by a team you contract.
Fabrx
Fields, as a structured record in the same shape every time.
A carrier changes its form
By hand
A person reads the new form and carries on.
Template OCR
The template stops matching and the fields have to be mapped again.
Outsourced processing
Absorbed by the provider, at whatever the contract says.
Fabrx
No change. Fields are read by what they are, wherever they sit on the page.
A document type you have not seen before
By hand
A person works out what it is.
Template OCR
No template exists, so nothing is extracted until one is built.
Outsourced processing
Handled, usually at a different rate.
Fabrx
Identified where we can, and set aside and reported where we cannot.
A document in another language
By hand
Somebody who reads that language, or a translation first.
Template OCR
Depends on the engine, and the published limits are often English only.
Outsourced processing
Depends who is staffed that day.
Fabrx
Read the same way, with no separate build for the language.
Where the output lands
By hand
Wherever the person types it.
Template OCR
A file or an API response. Getting it onto the claim is yours to build.
Outsourced processing
A spreadsheet or an upload, on a schedule the provider sets.
Fabrx
On the claim, through an endpoint you own or a call into your system.
What it costs to find out whether it works
By hand
Nothing, because it is what you do now.
Template OCR
Licence and setup, usually before you see your own documents run.
Outsourced processing
A pilot fee, or a minimum volume commitment.
Fabrx
Nothing. The build is free and you see it run on your documents first.
Someone has run this
They built solutions for any situation encountered along the way. For us, this type of partnership matters.
- 300+
- Field agents using it every working day
- 4,000+
- Documents processed every month
- 4 yrs
- In production, on the same workflow
Blitz is a real estate field agency network running identity documents into signed contracts. The figures are theirs and describe the pipeline on this page, running on different documents. No insurance deployment is being described here.
What a pilot measures
Measured on your documents
Field-level accuracy
Every field on every sample document, scored against your correction.
Sample size
How many of your real documents we ran. You choose which.
Classification accuracy
How often we identified the document correctly before reading it.
Exception rate
The share that stopped for a person, and what stopped them.
Build time
Calendar time from your samples reaching us to the pipeline running.
What we ask you for
How long does one document take today, from arriving to being on the claim?
It is the only honest denominator for any claim about time saved.
How many do you process in a month?
It sets the pricing band, because the rate depends on volume.
How many document types arrive in the same inbox?
It tells us how much of the work is identifying documents before reading them.
What does your OCR return today, and what happens to it next?
Most teams already have text. Knowing where it stops tells us what to build and what to leave alone.
What happens today when a field comes back wrong?
The cost of a wrong field decides how much of the pipeline should stop for a person.
What it costs
- 01
We build it
We build the extraction, usually within one business day of receiving your sample documents.
- 02
You check it
It costs you nothing until it runs on your real documents. If the accuracy is not good enough, nothing goes into production and nothing is charged.
- 03
Then you pay
A prepaid package priced per document, valid for a calendar year. The rate depends on the document type and your monthly volume.
- No subscription
- No per-seat charge
- No setup fee at any volume
Questions about insurance OCR
What is OCR in insurance?
Optical character recognition turns a scanned or photographed insurance document into machine-readable text. It gives you the characters on the page and where they sat. It does not tell you which of those characters is the policy number, the date of loss or the paid amount, which is the step that makes the output usable on a claim.
What happens between OCR and a claims decision?
Three things. The document is identified, so it is read against the right set of fields. The fields are pulled by what they are, wherever they sit on the page. Then the values are checked against each other and against the claim they arrived on. Anything that fails a check stops for a person before it reaches the file.
What is the difference between OCR and intelligent document processing?
OCR is the reading step and returns text. Intelligent document processing describes the whole path: identifying the document, extracting named fields, validating them, and delivering a record to a system. OCR is one part of that path, and on its own it leaves the hardest part with you.
Can OCR read handwritten claim forms?
We read handwritten documents routinely. Handwriting is ordinary input here, the same as a scan or a photograph of a printed page. On how well it reads your forms, we build on your own samples and measure field-level accuracy on them. If the result is not good enough, nothing goes to production and you pay nothing.
Does it work on documents that are not in English?
Yes. A document in another language is read the same way. This is worth checking against any tool you are comparing, because published English-only limits are common.
Do you store our documents?
No. Documents are not stored and they never train anything. If you switch on data lineage for auditability, fragments are kept encrypted for that purpose. An NDA is available, and redacted samples work fine for the build.
Related
- certificate of insurance processing
The same reading problem on one insurance document, with the ACORD 25 fields a compliance check runs on.
- automatic document processing
The same work described by its five steps, from capture through to the system it lands in.
- how the build works
The call, the sample documents, and what happens in the business day between them.
Send us twenty claims documents
We build the extraction and show you what it got right, field by field, before you pay anything.