Every manufacturer produces a diagnostic report in its own format, and an operation that handles thousands of them cannot read each one by hand. This guide sets out how to classify, extract and attach diagnostic data to the case so it is usable, searchable and defensible.
Pre-repair and post-repair scans, ADAS calibration reports, fault code read-outs and system health reports now accompany a large share of repairs and assessments. Each manufacturer's tool produces its own document, with its own layout, terminology and codes, and some change format between software versions. An operation receiving these from repairers, engineers and fleet customers sees dozens of formats a week.
The information inside them matters. Whether a fault was present before the repair, whether a safety system was recalibrated after a windscreen or bumper replacement, whether a code cleared or persisted, and what the vehicle's systems reported on the day are facts that decide repair scope, liability and safety. Read by hand, they are slow and error-prone to capture; filed as PDFs, they are unsearchable and effectively lost.
The record has to hold up later too. When a repair is questioned, when a vehicle has a subsequent fault, or when an insurer asks whether a calibration was done, the operation has to produce what the diagnostic report said, when it was received, and what was done about it, for a vehicle among thousands.
Every diagnostic report that arrives is classified first: which manufacturer and tool produced it, what kind of report it is, which vehicle it belongs to, and whether it is a pre-repair, post-repair or calibration record. Classification decides how the report is read and where it attaches. On SwiftCase this is done by the extraction layer, configured to the formats the operation sees, with new formats added as they appear rather than waiting for a model to be trained.
Extraction then reads the report into fields: the vehicle identifiers, the systems scanned, the fault codes with their status and description, calibration results, timestamps and the tool's own identifiers. The original document stays attached. The data becomes something the operation can search, compare and report on: every vehicle with an unresolved code in a given system, every calibration outstanding after a repair, every report from a given repairer.
Linked to the vehicle record and the case, the diagnostic history travels with the vehicle. An assessor looking at a new instruction sees what the vehicle reported last time; a quality check sees whether the post-repair scan cleared what the pre-repair scan found; a dispute is answered from the record of what the report said on the day.
Follow these steps to turn a stream of manufacturer documents into structured data on the vehicle and the case.
Collect a sample of every report type the operation sees by manufacturer, tool and report kind, and record the fields each one carries. This is the configuration the extraction layer will be built to, and the list will grow.
Vehicle identifiers, report type, tool and version, date and time, systems scanned, each code with its description, status and whether it was present or stored, calibration procedures and their results, and any tool identifiers. Define them once, for every format, so reports from different manufacturers are comparable.
Every incoming document is classified by manufacturer, tool, report type and vehicle before anything else, and attached to the right vehicle and case. Reports that cannot be classified with confidence go to a person with the reason, and what they decide teaches the configuration.
The extraction layer reads the report into the defined fields and shows the extracted value next to the part of the document it came from. A reviewer checks where confidence is low; the operation sets what low means. The original document stays attached to the record.
Where a case has a pre-repair and a post-repair scan, the case shows what was present before, what persists after and what is new, and flags calibration procedures the repair required that the post-repair record does not show. That check is automatic on every case, not a judgement someone has to remember to make.
Every report attaches to the vehicle record as well as to the case it arrived with, so the vehicle's diagnostic history is visible on the next instruction, whoever sent it and however long after.
Unresolved codes by system and age, calibrations outstanding after repairs, report volumes and classification rates by repairer and manufacturer, and turnaround from receipt to attached record. Reviewed regularly, these show where the process and the repairers need attention.
The extracted data is for searching, comparing and reporting. The document the manufacturer's tool produced is what the vehicle said, and it stays attached, unaltered, with its arrival recorded.
Tools update, manufacturers change layouts, new marques arrive. The process needs a route for the report it has not seen before, and a way to add it in days.
Mapping manufacturer codes to common categories makes reporting possible, but the mapping is a judgement. Record it, version it, and keep the original value beside the normalised one.
Low-confidence extractions go to a person every time. High-confidence ones are sampled on a schedule. Both results feed the configuration.
The check that a repair resolved what the pre-repair scan found, and that required calibrations were done, is where diagnostic data earns its keep. Build it into the case so it cannot be skipped.
Diagnostic data is most valuable on the next instruction. A history filed under the case that received it is a history nobody finds.
Set turnaround targets by instruction type and client.
Every assessment is a number somebody will argue with. This guide sets out a workflow that gets a practice from instruction to an estimate it can stand behind, consistently across assessors and at volume.
automotive assessmentMost of what a vehicle assessment relies on is a photograph. This guide sets out what to capture, how an image becomes evidence rather than illustration, how to treat images other people supply, and how to keep them so they still prove something years later.
automotive assessmentA practice with engineers in the field lives or dies by who gets which job and how fast it comes back. This guide sets out how to allocate by competence, location and capacity, set turnaround targets that mean something, and see the whole network at once.
Send us a week of diagnostic reports in whatever formats you receive and we will show you what they look like classified, extracted and attached to the vehicle, with the pre and post comparison running.
