Mass Tort Intake Data Model: Entities, States, Sources, and Corrections

A mass tort intake data model should represent each claimant, campaign, criteria version, answer, proposed fact, evidence item, source, correction, review, exception, consent record, and matter handoff as a distinct record. Stable IDs and explicit links show what came from where, what changed, and which authorized person owns the next decision.

The model supports the mass tort intake process and specializes the recordkeeping principles in the general legal intake guide. It is an implementation model, not a legal standard. The firm's lawyers or authorized staff define qualification rules, decide engagement, resolve legal questions, and approve the matter handoff.

Start with records, not one large claimant row

A single table with columns for every question fails when a campaign changes. One document can support several facts. Two sources may disagree about an exposure date. Flattening those events into one mutable row erases the reason for the current value.

Separate received information from reviewed assertions. An answer records a response to a versioned question. A fact records an assertion proposed from answers or evidence. Its state can change without rewriting the source, answer, or upload.

NIST's Data Governance and Management Profile concept paper identifies accuracy, timeliness, completeness, relevance, and consistency as data-quality factors. It notes added difficulty when data has several sources or uncertain provenance. Store lineage with each record, not in a later audit note.

Core entity and field model

Entity	Stable ID	Required fields	Key relationships	Human owner
Claimant	claimant_id	display name, identity state, contact state, created time	campaigns, answers, consents, handoffs	Intake operations owns identity reconciliation
Campaign	campaign_id	name, jurisdiction scope, active state	criteria versions, claimants, evidence requirements	Program owner controls configuration
Criteria version	criteria_version_id	version label, effective time, retired time, approval record	campaign, questions, rules, evidence requirements	Authorized firm reviewer approves and retires versions
Answer	answer_id	question ID, response state, value, received time	claimant, criteria version, source	Intake staff reviews collection exceptions
Fact	fact_id	fact type, value, assertion state, recorded time	claimant, supporting sources, corrections	Assigned reviewer accepts or disputes the assertion for intake use
Evidence	evidence_id	file hash, media type, received time, classification state	claimant, source, supported facts	Evidence queue owner resolves classification and readability
Source	source_id	source type, origin reference, captured time	answer, evidence, fact, correction	System records origin, staff resolves uncertain attribution
Correction	correction_id	target record, proposed value, reason, created time	prior value, source, reviewer	Named reviewer approves or rejects the correction
Review	review_id	review type, outcome, reviewer, completed time	record set, criteria version, exceptions	Assigned human reviewer owns the outcome
Exception	exception_id	exception type, severity, state, owner, due time	affected records, review	Queue owner resolves or escalates it
Consent	consent_id	consent type, text version, response, captured time	claimant, channel source	Firm policy owner defines the text and permitted use
Matter handoff	handoff_id	destination, package version, state, approved time	claimant, facts, evidence, reviews	Authorized firm staff approves release to the case system

Every entity needs created_at, created_by, and a version or event reference. Superseded records need superseded_by_id or an equivalent revision link. Use timezone-aware timestamps and store a file digest on evidence.

Stable IDs must survive corrected names and changed systems

Generate opaque IDs independent of name, email, phone, campaign label, or status. Those values change or repeat. Use a UUID, ULID, or database key. Store vendor and case-system IDs in an external identifier table with system, value, first_seen_at, and retired_at fields.

Deduplication should link possible matches before merging them. A confirmed merge retains both original IDs and points to the surviving ID. That keeps source links and consent events traceable.

Model provenance as a chain

The W3C PROV Data Model describes provenance through entities, activities, and agents. It also defines derivation, revision, attribution, generation, and invalidation. Those concepts map cleanly to intake without requiring an RDF database.

Intake event	Provenance question	Record link
A claimant submits a questionnaire	Who supplied which answer under which question version?	Answer points to claimant, criteria version, question, and submission source
A parser proposes a date from a record	Which file and location produced the value?	Fact points to evidence, page or region, extraction activity, and software version
A specialist corrects a product name	What changed, why, and who approved it?	Correction points to old fact, new value, supporting source, actor, and review
A rule flags a criteria mismatch	Which rule version generated the exception?	Exception points to criteria version, input records, rule ID, and evaluation activity
Staff send a matter package	Exactly which reviewed record set left intake?	Handoff points to a frozen package version, destination, approval, and delivery result

The PROV Ontology provides relations such as wasGeneratedBy, wasDerivedFrom, wasAttributedTo, and wasRevisionOf. A relational system can express them with foreign keys and event records. A current fact must retain its generating activity, source entity, and responsible agent.

Reliable mass tort document collection depends on separating evidence from source. Evidence is the received artifact, such as a photograph, record, label, or correspondence file. Source identifies the origin and acquisition context, such as upload, phone interview, referral import, or staff entry. One source event can generate several answers. One evidence item can support several proposed facts.

Keep answer, fact, and evidence states separate

Collection, assertion, evidence, and workflow each need a small state machine.

Record	State	Meaning	Permitted owner action
Answer	unanswered	The approved question has not received a response	Continue the interview or follow-up
Answer	unknown	The person was asked and stated that the answer is not known	Request an available source or route for review
Answer	reported	The claimant or another identified person supplied the value	Retain the source and compare with evidence
Fact	proposed	A value was derived from an answer or evidence item	Reviewer checks support and scope
Fact	disputed	Sources or reviewers disagree	Keep each assertion and open an exception
Fact	reviewed	An authorized reviewer accepted the value for the stated intake purpose	Record reviewer, time, and criteria version
Evidence	requested	A defined evidence item has not arrived	Follow up under firm policy
Evidence	received	Bytes arrived and the receipt event was recorded	Hash, scan, and classify the file
Evidence	unreadable	The item cannot support extraction or review	Request a clearer copy or human inspection
Evidence	classified	Staff or an approved process assigned an evidence type	Connect it to requirements and proposed facts
Exception	open	A named issue prevents the expected transition	Assign owner and due time
Exception	resolved	A person recorded the disposition and support	Resume the permitted transition

unknown and unanswered must remain distinct. A blank value cannot tell the next worker whether to ask the question, request a document, or accept that the information is presently unavailable. A negative answer also needs an explicit value. It should never be stored as an empty field.

Version criteria and decisions together

Each campaign criteria release should be immutable after approval. Create a new criteria_version_id when the firm changes a question, evidence requirement, rule, threshold, or permitted path. Store effective_at, retired_at, approved_by, and approval_review_id. Answers always point to the version presented to the person. Rule evaluations always point to the version executed.

Do not silently rerun old records under new criteria. A new evaluation activity reads the existing record set and produces a new review or exception while the prior result remains available.

Qualification is not a software-owned status. A rule can produce criteria_match_proposed, criteria_gap, or review_required. A lawyer or authorized firm reviewer decides whether the matter advances, needs another step, or stops under firm policy. Store that decision as a review record with its input set and criteria version.

Treat corrections as append-only decisions

Editing a fact in place destroys the difference between what arrived and what a reviewer later concluded. A correction should name the target record, prior value, proposed value, reason code, supporting source, proposer, and disposition. Approval creates a new fact revision and marks the prior revision as superseded. Rejection preserves the proposal and reason without changing the active value.

Mass tort intake quality assurance needs the same lineage. The W3C Data Quality Vocabulary separates quality dimensions, metrics, measurements, policies, and annotations. Intake teams can apply that principle by defining a measure such as missing-document rate and storing its numerator, denominator, scope, calculation time, and generator. A person then judges whether the result fits the campaign's purpose.

Never convert a quality score into an automatic legal conclusion. A completeness check can show that required fields are present. It cannot decide whether the evidence proves a claim, whether a conflict is cleared, or whether representation should begin.

Make workflow transitions inspectable

The claimant record can move through a controlled workflow while its answers, facts, and evidence retain their own states.

Workflow state	Entry requirement	Exit authority
received	Original source and claimant ID recorded	Intake operations may start identity review
identity_review	Duplicate search and identity exceptions visible	Assigned staff may continue collection
collecting	Criteria version and evidence requirements fixed	System may mark preparation complete when configured checks pass
exception_review	Each blocking issue has an owner	Assigned human resolves or escalates each exception
ready_for_attorney_review	Required preparation checks passed and unresolved gaps are visible	Authorized reviewer records the decision
engagement_pending	Firm decision and required approvals recorded	Authorized firm staff completes engagement controls
handoff_ready	Reviewed package version frozen	Authorized firm staff approves delivery
handed_off	Destination acknowledged the exact package version	Case-system owner accepts custody
closed_intake	Firm-approved disposition and retention action recorded	Reopening requires a new review event

The handoff package should reference IDs and versions, not unlinked display values. Include the claimant ID, campaign ID, criteria version, active fact revisions, evidence IDs and hashes, open exceptions, consents, and reviews. If the destination needs flattened fields, retain a mapping from each export to its source entity and package version.

Implementation checks before launch

Test difficult records before opening a campaign, including a duplicate claimant, unknown date, contradictory document, criteria change, rejected correction, unreadable upload, withdrawn consent, and failed handoff. Confirm that the source remains available, the next owner is named, and no automated step crosses the firm's human decision boundary.

Then inspect five controls:

1. IDs remain stable after corrected contact details and system synchronization.
2. Every fact can be traced to an answer, evidence item, or named reviewer action.
3. Every criteria result identifies the version that produced it.
4. Every correction preserves the prior value and approval history.
5. Every handoff identifies the exact record set delivered and its receiving system.

A sound data model makes missing, unknown, conflicting, and corrected information visible to the decision owner. It lets a mass tort team prepare a review-ready case file without losing the record's history.

Book a demo →