Extracting Claims Data From a Workers' Compensation First Report of Injury

The first report of injury is the document that opens a claim, and its hardest field is the one that looks easiest. A form gives you one box for the part of the body affected. An employee who slipped and hurt their lower back and their right shoulder has two, and the form cannot hold that.

One document type, fifty layouts

There is no single first report of injury. Each United States jurisdiction prescribes its own paper form, with its own field order, its own labels and its own numbering. What is shared is the electronic layer beneath: the IAIABC claims release standard defines the FROI and SROI transactions with numbered data elements and published code lists, which is what carriers and state agencies actually exchange.

That gives the extraction a target worth aiming at. Rather than modelling the fields of whichever paper form is in front of you, map to the standard’s data elements and keep the form’s own field label as provenance on each value. A pipeline built form by form needs rebuilding for every state; one built to the exchange standard needs a new mapping table instead. The IAIABC publishes the standard and its code lists, and those are the authority for element numbers and permitted values — check them rather than any summary, including this one.

One narrative, several body parts

Injury data is coded on three axes that are separate in the standard and blurred on the paper form: the nature of the injury, the part of body affected, and the cause of the injury. The form frequently offers one box for each and a free-text description of the accident that contains all three and more.

The specific failure is a multi-part injury. “Slipped on a wet loading dock, landed on his back and struck his right shoulder on the rail” describes at least two injured parts, one of which carries laterality. In most code lists, laterality is not part of the body-part code — it is a separate attribute — so “right shoulder” decomposes into a part and a side. And the form’s single box can hold one of the two parts at most.

The extraction should therefore emit an array regardless of the form’s shape, and record what the form’s own field said separately from what the narrative supports:

{
  "body_parts_from_form":      [ { "text": "back", "code": "…", "side": null } ],
  "body_parts_from_narrative": [
      { "text": "lower back",     "code": "…", "side": null,    "span": [42, 52] },
      { "text": "right shoulder", "code": "…", "side": "right", "span": [78, 92] }
  ],
  "primary_part": null,           // not chosen by the pipeline
  "discrepancy": "narrative_has_additional_parts"
}

Leaving primary_part null is deliberate. Some jurisdictions require a most-severe or primary part to be designated, and that is a judgement about the injury rather than a fact on the page. The pipeline’s job is to surface that both parts are described and that the form recorded one; an adjuster decides. A model asked to pick will pick, every time, with no signal that it did.

Vocabulary variance makes the coding step harder than a lookup. Narratives use lay terms, clinical terms and slang for the same structure, and a code list uses one term per code. Constrain the model’s output to the code list as an enumeration and require a span into the narrative for each code, so a reviewer can see the words that produced it. The general treatment of constrained outputs is in structured output support.

Three dates that are not interchangeable

First reports carry a cluster of dates with similar labels and very different meanings: the date of injury or onset, the date the employer knew of it, and the date of the first full day of lost time. Others appear too — date reported to the carrier, date of return to work, date the form was completed.

These must be bound to their labels rather than gathered by pattern. A model given “extract the date of injury” and a form with six dates on it will return one of them, and the ones that are close together in space are the ones most easily confused. Extract every date field as a labelled pair and let the mapping to standard elements happen afterwards, where it is inspectable.

Occupational disease is the case that breaks a date field outright. Where a condition developed over time, the date of injury may be stated as a date of last exposure, a date of diagnosis, or a range, and some forms provide a separate field for it. Model the injury date as a range with a stated basis rather than a point, in the same way an alleged period is modelled on a charging document.

Keep the narrative, add the codes

The accident description is the richest field on the form and the one most often destroyed by extraction. Coding it is useful; replacing it is not. Store the verbatim text alongside every code derived from it, with character spans linking the two, because the coded value answers reporting questions and the text answers everything else, including the question of whether the code is right.

Wage and hour fields deserve one specific caution: they are numeric, handwritten more often than not, and formatted inconsistently, and a misplaced decimal in an average weekly wage propagates into benefit calculations. Extract them with their own amount validation against any stated pay period and hours, and route anything ambiguous to review rather than accepting a plausible number.

What the form carries that you should not send

A first report is dense with identifiers: name, date of birth, home address, a national identification number in many state forms, and often the beginning of a medical history. The organisation processing it holds it lawfully; that does not mean all of it needs to go to a model.

Send the minimum the extraction actually needs. The narrative, the injury fields and the date block support coding; the identity block usually does not, and can be masked or cropped before the page leaves your infrastructure and reattached afterwards by document identifier. Where the document leaves your control at all, the arrangement with the processor is the thing that matters — a data processing agreement, an explicit retention setting, and a check that prompts and responses are not being logged with the identifiers still in them. The general treatment is in PII redaction and PII in LLM logs.