Mass Tort Intake Metrics: Measure File Readiness, Not Form Volume

Mass tort intake metrics should show whether each claimant record is complete enough, supported enough, and clearly enough owned for an attorney to review. Form submissions alone measure arrival volume. A useful scorecard defines the record population, required evidence, workflow events, exception states, and review boundary before it calculates a rate.

Measure fitness for review, not activity

Mass tort programs receive many records through forms, calls, referrals, imports, and document uploads. Counting each event can describe traffic, yet it cannot show whether the resulting files can support a decision. Ten submissions may represent ten people, repeated attempts by one person, imported duplicates, or records that lack the evidence the firm's review policy requires.

The operational purpose of measurement is therefore specific: show how reliably the mass tort intake operating model turns received information into a traceable file at the attorney-review boundary. The measures below also assume a defined mass tort intake process. A dashboard cannot repair a workflow whose stages, owners, and exit rules are undefined.

The U.S. Government Accountability Office's data reliability guide treats reliability as a question of accuracy, completeness, and suitability for an intended purpose. NIST's Research Data Framework likewise describes quality assessment in relation to planned use and identifies accuracy, completeness, consistency, and timeliness as useful dimensions. Applied to intake, the intended use is a review packet that an authorized reviewer can understand without reconstructing the record from scattered systems.

Establish the measurement contract first

Every metric needs a short contract stored beside the dashboard definition. The contract should name its purpose, numerator, denominator, unit, cohort, exclusions, source events, owner, refresh time, and version. Without that contract, two teams can publish the same label while counting different work.

Define the population before choosing a denominator. A received record is a unique intake record created when the system accepts an inquiry. A person is a deduplicated identity that may be linked to more than one received record. A review packet is a versioned assembly submitted to a defined review queue. These units are not interchangeable.

Also decide whether a report follows a submission cohort or a process event. A submission cohort groups records by received_at and follows their later outcomes. An event report counts work that occurred during a period, even when the underlying record arrived earlier. Cohorts show what happened to a set of arrivals. Event reports show current workload. A useful operations view usually labels both instead of blending them.

NIST's Data Governance and Management Profile concept paper connects governance objectives with roles, policies, metadata, lineage, and accountability. The federal Data Strategy practices similarly call for assigned governance roles, maintained documentation, provenance, standards, and data quality aligned with intended use. Those principles support a practical rule: the metric definition, the events that feed it, and the person accountable for investigating it all need named ownership.

Use explicit event boundaries

A status label describes the record now. An event records what happened at a point in time. Metrics should derive from immutable or append-only events wherever possible so a later status change does not erase earlier work.

At minimum, define these boundaries:

Event	Boundary	Required properties
intake_received	The system accepts the first source submission and creates a record ID	record ID, source, received time
intake_stage_entered	A record first becomes eligible for work in the named collection stage	stage, requirement-set version, entry time
intake_stage_completed	All requirements for the named collection stage are answered, explicitly unknown, not applicable, or waived under firm policy	stage, requirement-set version, completion time
evidence_requirement_opened	A configured evidence requirement becomes applicable	evidence type, rule version, opened time
evidence_received	A source file is attached and classified against that requirement	source ID, classification, received time
correction_recorded	A material field value changes after initial capture	old value reference, new value, source, actor, reason, time
duplicate_confirmed	An authorized workflow confirms two records represent the same person or inquiry	retained ID, linked ID, reviewer, time
exception_opened	A record cannot follow the ordinary next step	exception type, owner, opened time
exception_resolved	The blocking condition is addressed or dispositioned	resolution, actor, resolved time
review_packet_submitted	A versioned packet enters the attorney-review queue	packet version, requirement-set version, gate-result snapshot, submitted time
review_packet_returned	The reviewer sends the packet back for intake remediation	reason code, reviewer, returned time
review_packet_reviewed	An authorized reviewer records the first response to a submitted packet version	response type, reviewer, reviewed time

Do not overwrite a received fact to make the current record look clean. The National Archives' electronic recordkeeping guidance calls for audit trails of additions, updates, deletions, retrievals, and other record activity. An intake correction history serves the same operational need. It lets a reviewer distinguish what arrived, what changed, who changed it, and which source supported the change.

Metric dictionary for file readiness

The table gives implementable definitions, not benchmarks. Each firm must set its own review policy, evidence requirements, reporting window, and alert thresholds.

Measure	Formula	Denominator and boundary	Primary owner	Caveat
Stage completion rate	Unique records with intake_stage_completed / unique records that entered the stage	Cohort by first stage-entry event	Intake operations	Completion means the configured stage rules were satisfied. It does not mean the claim qualifies.
Missing-evidence rate	Unique submitted packets with at least one open required-evidence item / unique packets submitted for review	First review_packet_submitted per record and requirement-set version	Evidence operations	Separate unavailable evidence from evidence never requested. Requirements can change by campaign and version.
Correction rate	Unique reviewed records with at least one material correction_recorded / unique records reviewed	Review event for the same cohort and field dictionary version	Data steward	Count records for the rate and retain event count as a diagnostic. A correction can reflect good review, not poor staff performance.
Duplicate rate	Records confirmed as duplicates / candidate records created	duplicate_confirmed events tied to the creation cohort	Intake operations	A stronger identity check can increase the observed rate while improving record quality. Exclude system tests and documented spam by rule.
Open exception age	Report time minus exception_opened for unresolved exceptions	Each unresolved exception at the report cutoff	Queue owner	Report age by exception type and owner. One combined average can hide an old tail.
Remediation rate	First-submission packets returned for intake remediation / first-submission packets reviewed	First review_packet_submitted and its first reviewer response	Review operations	Do not count a legal judgment request as intake remediation. Use controlled return reasons.
Attorney-review readiness rate	Packets that satisfy all configured operational gates at submission / packets submitted to attorney review	Submitted packet version under the active requirement-set version	Program operations	Readiness is an operational state. It is not an opinion on merit, conflicts, engagement, or filing.

For duration measures, publish the median and a tail percentile chosen in the metric contract, along with the record count. Do not hide open work by calculating only resolved exceptions. A backlog view should include every unresolved item as of the report cutoff. A flow view should show items opened and resolved during the same period.

Preserve unknown, unanswered, and unavailable states

An unanswered question means the workflow has no recorded response. An unknown answer means the claimant was asked and could not provide the fact. An unavailable document means the requirement was evaluated and the document cannot currently be supplied. These states require different next actions and must not collapse into a blank value.

Stage completion may permit an explicit unknown when the firm's rule says the interview step is complete. Review readiness may still block if that unknown concerns a required operational fact. Missing-evidence reporting should count an applicable open requirement, not every empty upload slot. A mass tort intake checklist should state which conditions allow completion, create an exception, or require human review.

Unknown is also not a negative answer. If a record asks whether a person has a particular source document, unknown, not yet requested, requested, received, unavailable, and not applicable should remain distinct allowed states. That state model makes the numerator reproducible and tells the queue owner what to do next.

Assign ownership and review the causes

The intake operations leader owns stage definitions and queue performance. The data steward owns field definitions, allowed values, correction lineage, and metric logic. Evidence operations owns document requirements and classifications. Review operations owns return reasons and the boundary between remediation and legal review. Engineering or analytics owns event integrity, joins, refreshes, and versioned queries. Privacy and security staff approve access and retention controls.

Lawyers or other authorized firm staff retain decisions about conflicts, legal merit, engagement, filing, and legal advice. Software can test whether configured operational requirements are met. It should not convert attorney-review readiness into an automated qualification or engagement decision.

Review a metric by campaign, requirement-set version, source, intake stage, exception type, and owner where the sample supports a responsible comparison. Investigate the workflow behind a change. A rising correction rate might show an unclear question, a new reviewer practice, improved source checking, or a changed field definition. A rising duplicate rate might indicate repeated acquisition records or better matching. The number alone does not establish the cause.

Book a demo →

Build the scorecard from a governed record

Start with the general legal intake model, then document the event dictionary, field dictionary, requirement versions, and packet versions used by the mass tort program. Run the formulas against a small known set and reconcile every numerator to its source records. Test late documents, reopened exceptions, merged duplicates, corrected answers, changed requirements, and packets submitted more than once.

Publish a metric only when an operator can trace it from the dashboard to the event, record, source, and rule version that produced it. That traceability turns intake reporting into a control for file readiness. It also keeps the scorecard honest about what it can measure: the condition of the operational record before legal judgment begins.