Inside a medical malpractice submission: what InsightXtract extracts — and why it matters

Medical malpractice — medical professional liability, or MPL — is a line where the details decide everything. Two practices with identical revenue can carry wildly different risk depending on the specialty of the physicians, how many of them are board-certified, which states they’re licensed in, and whether last year’s open claim is a nuisance suit or a seven-figure reserve. The submission itself is compact — a broker’s email with the ask and a medical malpractice application — but the information that actually rates the account is buried in a provider schedule, a claims table, and a set of coverage terms that only mean something in relation to each other.

Most intake tools read one document at a time and hand back a flat list of fields. That is not how an MPL account is underwritten. InsightXtract runs an agentic, multi-document pipeline that classifies each file, extracts to a per-document schema, consolidates everything into one unified account record, links it into an entity graph, and validates it against your rules and reference data — so the underwriter opens a single, coded, cited record instead of a stack of PDFs.

One submission, two documents, one connected record — classify, extract, consolidate, link, validate.

The idea that governs everything: specialty and providers are the price

Before the categories, the single most important concept. In medical malpractice, the exposure isn’t the entity — it’s the people and what they do. A ten-physician group tells you almost nothing; a ten-physician group where three are neurosurgeons and one is an OB/GYN is a very different risk from ten dermatologists, and the rate should reflect that. The same is true of coverage: an each-claim limit means one thing on an occurrence policy and quite another on a claims-made policy with a retroactive date that leaves a gap. So the extraction is built to capture the provider roster and the claims history as full tables, and the coverage terms as an interlocking set — not scattered single values.

In the tables below, the Type column flags how each parameter is captured:

• Point-in-time — a single static fact about the account.
• Current — a value for this term’s coverage or exposure.
• Per-row — a table: one provider, or one claim, per row.

A · Insured identity & legal structure

Who the account is — the contract party, its identifiers, and where the risk sits. Source: application form.

Parameter	Type	Why it matters
Insured name · DBA	Point-in-time	The contract party and unique account key — drives clearance, conflicts, and de-dupe.
FEIN · entity type	Point-in-time	Federal ID and legal form — solo, group, PC/LLC, or facility changes how the policy is structured.
Address · risk state	Point-in-time	Venue is decisive in MPL — some states are far more plaintiff-friendly and carry tort-reform differences.
NAICS · SIC code	Point-in-time	Class-based rating and appetite/knockout — standardised against reference tables.

B · Broker & submission

Who’s placing the account and the shape of the ask — the distribution chain and the transaction. Source: broker submission email.

Parameter	Type	Why it matters
Broker name · broker email	Point-in-time	Distribution routing, binding authority, and correspondence.
Product	Current	The exact line being requested — med-mal / MPL — and the coverage form that follows.
Effective date	Current	Term start and the binding deadline — standardised to a canonical date.
Requested limit	Current	The capacity the broker is asking for — the headline of the ask, reconciled against the application limits.

C · Entity & practice profile

The operational shape of the practice — what kind of medicine it is, at what scale, and with how many people. This is where MPL exposure is really defined. Source: application form.

Parameter	Type	Why it matters
Business description · years in business	Point-in-time	Nature of operations and stability credit — a new practice underwrites differently from an established one.
Facility type	Current	Solo office, group clinic, surgery center, or hospital — drives the hazard band and the coverage form.
Primary specialty	Current	The single biggest severity driver — surgery and OB carry a far higher claim cost than primary care.
Physician count · number of providers	Current	The core exposure unit — MPL is largely rated per provider.
Annual patient encounters · annual procedures	Current	Volume of exposure — more encounters and procedures means more frequency opportunity.
Employee count · total payroll · estimated revenue	Current	Scale of operations and the secondary exposure base — standardised to currency for rating.

D · Coverage & limits

The exact shape of the cover being requested. In MPL these terms only mean something together — the trigger, the retroactive date, and the tail decide whether the limit is real. Source: application form.

Parameter	Type	Why it matters
MPL limit (per-claim / aggregate)	Current	The headline capacity — standardised to currency and reconciled against the requested limit.
Each-claim limit	Current	The most a single suit can recover — the primary severity cap.
Aggregate limit	Current	Total annual capacity across all claims — matters most for high-frequency specialties.
Claims-made vs. occurrence	Current	The coverage trigger — the fundamental structural decision in MPL that governs everything below.
Retroactive date	Current	On a claims-made policy, how far back prior acts are covered — a gap here is uncovered exposure.
Tail coverage	Current	Extended reporting for claims made after the policy ends — a major cost and continuity factor.
Prior carrier · premium	Current	Coverage continuity and the rate-change baseline — the price-to-beat on a renewal or move.

E · The provider schedule — one row per provider

The heart of an MPL rating. InsightXtract reads the provider roster as a table — one row per physician or provider — because the mix of specialties, licenses, and credentials is what actually prices the account. Source: application form.

Parameter	Type	Why it matters
Per provider: provider name	Per-row	Identifies the covered individual — the unit that carries the risk and the premium.
Per provider: specialty	Per-row	Per-provider severity class — the specialty mix drives the blended rate more than any single field.
Per provider: license state	Per-row	Venue exposure per provider — multi-state rosters spread the account across differing tort regimes.
Per provider: years experience	Per-row	A frequency signal — very new and very senior providers carry distinct claim patterns.
Per provider: board certified	Per-row	A credential and risk-quality marker that often earns a rating credit.

F · Claims history — one row per claim

The single biggest pricing input after specialty. InsightXtract reads each claim as a row and standardises the financial values so the loss picture is comparable and computable. Source: application form.

Parameter	Type	Why it matters
Per claim: claim number · date of loss	Per-row	Each loss’s identity and timing — date is standardised to a canonical format for trending.
Per claim: description	Per-row	The nature of the allegation — the qualitative signal of severity and escalation potential.
Per claim: status (open / closed)	Per-row	Open claims are live exposure still developing on the books.
Per claim: paid · reserve · incurred	Per-row	Cost to date, remaining exposure, and total incurred — standardised to currency for rollups and loss-ratio math.

From two documents to one connected record

Pulling these parameters out of two documents is only half the job. The value is in consolidation: the insured named on the application, the broker on the email, the coverage terms, the provider roster, and the claims all describe one account. InsightXtract merges them into a single record by a declared source-of-truth priority — when the application and the email disagree on the insured name or the limit, the application-form value wins — and links the result into an entity graph: the insured at the centre, connected to broker, submission, coverage, the provider schedule, and the claims history. Every value is standardised against reference data — state codes and NAICS codes are validated against lookup tables, currency and date fields are normalised — and each field is cited back to the page it came from.

Why it matters to the business

Comprehensive, structured extraction of an MPL submission isn’t a data-entry nicety — it changes the economics and quality of the book:

• Specialty is severity. Capturing the primary specialty and the per-provider specialty on the schedule lets you rate to the real hazard mix instead of a single blended guess — the difference between a priced surgical exposure and a surprise.
• Provider mix is the exposure unit. The number of providers, their licenses, experience, and board certification are exactly the fields that move an MPL rate — extracting the whole roster as a table means none of them get lost.
• Claims-made and tail are structural. The trigger, retroactive date, and tail decide whether the limit is real. Pulling them together, standardised, means coverage gaps surface at intake — not in a claim dispute.
• Encounter volume is frequency. Annual patient encounters and procedure volume are the frequency base — capturing them by default lets the model weigh exposure against the loss history.
• Consistency and auditability. The same categories, coded and standardised the same way, every time — with provenance to the source document and reference-data validation on state and NAICS codes. That is the difference between a repeatable book and one that depends on which underwriter opened the file.

The Medical Malpractice agent extracts all of this today — the insured identity, broker and submission, the practice and specialty profile, the full claims-made coverage and limits, the provider schedule, and the claims history — consolidated into one coded record of 30+ fields and two linked tables, every value standardised and cited to its source document. The point this post makes is why it matters: specialty, provider mix, and the claims-made structure are exactly what move an MPL price, so they’re captured by default. And because it’s all configuration — fields and tables in the agent’s output contract, not code — the schema keeps pace with what underwriters ask for.