Extracting OSHA Recordable Fields From an Incident Report

Most document extraction produces fields somebody then has to interpret. This one is unusual: the interpretation is a published decision tree with defined inputs, so the useful output is the set of facts the tree consumes, each tied to the criterion it feeds and to the words in the report that support it.

Recordability is a published decision tree

The recording criteria live in 29 CFR Part 1904, published by the Occupational Safety and Health Administration. The structure runs in order: is the case work-related, is it a new case, and does it meet one of the general recording criteria. The criteria at 1904.7(a) are death, days away from work, restricted work or transfer to another job, medical treatment beyond first aid, loss of consciousness, and a significant injury or illness diagnosed by a physician or other licensed health care professional. The regulation text is at OSHA’s published copy of 1904.7 and it is the authority; everything below is a paraphrase written to show what the extraction has to produce, not a substitute for reading it.

Design the schema around the tree. Each criterion becomes a field with three values — satisfied, not satisfied, insufficient information — plus the supporting quote from the report. That third value is the missing required field case with a name, and it is the important one here, because an incident report very often does not say whether the employee lost consciousness or what the clinic actually did, and a pipeline that reports those as “no” is asserting something the document does not.

Work-relatedness has its own structure at 1904.5, including a list of exceptions covering things such as an employee eating their own food, personal grooming, and certain voluntary activities. Extract the facts those exceptions turn on — where the employee was, what they were doing, whether it was in the work environment — rather than attempting a conclusion. Recordability is a determination made by the employer’s recordkeeper, and the extraction exists to give them the evidence with citations, not to replace them.

The first-aid list is closed

The distinction between medical treatment and first aid is the criterion most often argued about, and it is also the most mechanical, because the regulation defines first aid as a closed list rather than as a standard. If the treatment given appears on the list at 1904.7(b)(5)(ii) it is first aid; if it is treatment and it is not on the list, it is medical treatment.

The list includes, among others, non-prescription medication at non-prescription strength, tetanus immunisations, cleaning or flushing surface wounds, wound coverings such as bandages and butterfly bandages, hot or cold therapy, non-rigid support such as elastic wraps, temporary immobilisation used while transporting an accident victim, draining fluid from a blister, eye patches, removing foreign material from the eye by irrigation or swab, removing splinters by tweezers or similar simple means, finger guards, massages, and drinking fluids for heat stress. Read the current text for the full and authoritative list.

What this gives the extraction is a lookup rather than a judgement. The field to extract is what was done, verbatim, from the treatment section of the report — and the classification then compares it against the list. Sutures, prescription medication and physical therapy are not on the list; an ice pack and a bandage are. Because it is a closed list, an unmatched treatment description is a meaningful output: it means somebody has to look, not that the answer is first aid.

Two related notes worth capturing as fields. The regulation treats treatment as medical treatment regardless of who provided it, so “the site nurse did it” is not itself a classification. And a visit to a clinic solely for observation or diagnostic procedures is treated differently from a visit for treatment, so extract the stated purpose of the visit alongside what was done.

Counting days is arithmetic with rules

Where a case involves time away or restricted duty, the counts are governed by rules that make them computable from dates in the report. Counting is in calendar days, begins on the day after the injury or illness occurred, includes weekend days and holidays the employee would not have worked anyway, and is capped at 180 days.

Synthetic case
  injury occurred                 Thu 2026-05-14
  employee off work               Fri 15, Sat 16, Sun 17, Mon 18 May
  returned on restricted duty     Tue 2026-05-19
  restriction lifted after        Fri 2026-05-29

Days away (column K)
  count begins the day AFTER the injury          → 15 May
  calendar days away: 15, 16, 17, 18             → 4
  weekend days count even though not scheduled

Days on job transfer or restriction (column L)
  19 May through 29 May inclusive                → 11

Case classification: the case has BOTH days away and restricted days,
so it is entered in the most serious applicable column — days away —
and both day counts are still entered in K and L.

The day of the injury itself is never counted, and a restriction or absence confined to the day of the injury alone does not by itself satisfy the restricted-work or days-away criteria. That single rule resolves a large share of borderline cases, and it is exactly the kind of detail an extraction can support by capturing dates precisely rather than capturing a summary such as “lost a couple of days”.

So the fields to extract are dates and status changes, not durations: date of injury, each date the work status changed, and the status it changed to. Durations are derived, and a derived number that can be recomputed from stored dates is auditable in a way that a transcribed duration never is.

One column, the most serious outcome

The OSHA Form 300 log classifies each case in one of four columns: death, days away from work, job transfer or restriction, and other recordable cases. Only one is checked, and it is the most serious outcome that applies. Two further columns hold the counts — days away, and days on job transfer or restriction — and both are filled in where both occurred, as in the worked example above. The DART measure that safety teams track is built from the two middle columns.

For the extraction this means the classification output is a single enumerated value plus two integers, with a severity ordering that is fixed rather than a matter of preference. It also means a case can move between columns after it is first logged, because a case that starts as restricted duty and becomes days away is updated. Store the log entry with an effective date, keep the field-level audit trail, in the same way a claim status history is kept rather than overwritten.

Privacy concern cases change the output

The recordkeeping rules define a category of privacy concern cases — particular case types set out at 1904.29 — for which the employee’s name is not entered on the log at all; the entry says that it is a privacy case and the name is kept on a separate, confidential list.

This is a genuine constraint on the pipeline rather than a note in passing, because it means one of the extraction’s outputs is a decision about whether a name may appear in the record it is writing. The safe construction is to keep identity in a separate store from the incident facts by default, joined by an internal case identifier, so that suppressing a name is a matter of not joining rather than of scrubbing a field after the fact.

The same separation helps with what leaves your infrastructure. An incident report contains the employee’s name and often clinical detail, and very little of that is needed to classify treatment against a closed list or to read dates off a status section. Send the treatment description and the date block, keep the identity block local, and apply the ordinary discipline about processor agreements and retention that a first report of injury needs for the same reasons.