How ADE processes insurance claims packages containing forms, photos, repair estimates, police reports, and handwritten notes without per-carrier templates.
Insurance claims intake is document processing in its hardest form: each claim arrives as a different combination of document types, from different sources, in different formats, with no consistent structure across carriers or claim types. ADE processes the entire claims package through a single parse step and extracts each document type using a schema, without per-carrier or per-document-type configuration.
What a Claims Package Contains
A property or auto claim package typically includes a subset of:
- Claim forms. Carrier-specific first notice of loss (FNOL) forms, coverage verification sheets, and claimant declarations.
- Supporting evidence. Photos of damage, repair shop estimates, invoices, and receipts. These arrive as images or image-embedded PDFs alongside text documents.
- Third-party records. Police reports, fire marshal reports, weather service records, and independent adjuster assessments.
- Identity and policy documents. Claimant ID, policy declarations pages, and certificates of insurance.
- Handwritten notes. Field adjuster notes, claimant-written statements, and annotated diagrams.
Each of these requires a different extraction schema. The same parsed Markdown output from the Parse API is reused across all extract calls, so the package is parsed once and queried once per document type without re-processing.
Processing Mixed Document Types
ADE's Document Pre-Trained Transformer architecture identifies document structure visually, handling the structural diversity of a claims package without per-type configuration. A repair estimate with a cost table parses with table structure preserved.
A police report in narrative form parses as ordered text blocks with section headings. A photo of vehicle damage returns as a figure chunk with coordinates.
A handwritten claimant statement parses as text using the same visual reasoning as a printed form.
Every element across all document types in the package carries page number and bounding-box coordinates in the parsed output. This grounding survives the extraction step: when a claim amount is extracted from a repair estimate, the bounding-box citation points to the exact line item in the estimate table.
Extraction Schemas by Document Type
Each claims document type has a distinct extraction schema. Key fields by type:
| Document type | Key extracted fields |
|---|---|
| FNOL form | Claimant name, policy number, date of loss, location, incident description, reported damages |
| Repair estimate | Shop name, vehicle details, repair line items (array), parts costs, labour costs, total estimate |
| Police report | Report number, date and time, officers involved, incident narrative, parties identified |
| Policy declarations | Policy number, named insured, coverage types and limits, effective dates, deductibles |
| Claimant statement | Claimant name, incident date, statement narrative, signature presence (attestation) |
Schemas are validated against sample documents in the Schema Wizard Playground before production integration.
Handling Handwritten Content
Field adjuster notes and claimant statements frequently contain handwritten text; ADE's visual-first parsing handles handwritten content using the same architecture as printed text, identifying handwriting as a text chunk type with spatial grounding. Extraction accuracy on handwritten content is reflected in confidence scores for affected fields, routing low-confidence handwritten extractions to adjuster review.
Confidence Routing in Claims Workflows
Claims processing cannot propagate wrong values into reserve calculations or coverage decisions. Each extracted field carries a confidence score enabling the pipeline to route uncertain extractions to a human adjuster with the bounding-box citation pre-populated.
The adjuster confirms or corrects the value at the specific location rather than re-reading the entire claim file.
Zero Data Retention is available for carriers whose policies require that claims documents not be stored on third-party infrastructure during processing. SOC 2 Type II certification and HIPAA BAA availability are documented at the Trust Center.
FAQ
Can ADE process a claims package that arrives as a single combined PDF? Yes. The entire package is submitted to the Parse API or Parse Jobs API as a single file; the parsed output preserves the structure of every document type across all pages.
Multiple extract calls with different schemas then pull fields from each document type without re-parsing.
How does ADE handle photos of damage embedded in a claims PDF? Photos and images within a document are identified as figure chunk types with bounding-box coordinates in the parsed output. ADE's extraction schema can reference figure chunks for metadata (page number, location, caption), though pixel-level image analysis for damage assessment is outside the scope of document extraction and requires a dedicated vision model.
Does ADE require different configurations for different carriers' claim forms? No. ADE's visual-first architecture handles layout variation without per-carrier templates.
The extraction schema defines which fields to extract; field descriptions in the schema guide the extraction model to recognise the same logical field across different carriers' label conventions and layout choices.
How does ADE handle claims packages with both digital PDFs and photographed documents? ADE accepts PDFs and images through the same Parse API. Both are processed using visual-first parsing; photo quality affects extraction certainty, which surfaces in confidence scores that route lower-quality extractions to adjuster review.
What compliance requirements does ADE support for insurance claims data? ADE provides Zero Data Retention for in-memory processing without storage, SOC 2 Type II certification, and VPC deployment for carriers requiring that claim data not transit third-party infrastructure. See the Trust Center for current certifications and compliance documentation.