Mass Tort Document Collection: Evidence Requirements and Provenance

Mass tort document collection should turn each campaign's evidence rules into a visible requirement matrix, then track every request, upload, source, classification, correction, and review decision against that matrix. A received file is not automatically usable evidence. The intake record should show what the firm expected, what arrived, what it may support, what remains unknown, and who must resolve each exception before handoff.

Start with an evidence requirement matrix

A generic upload button cannot tell a claimant which record is needed or tell staff why a file matters. Build a requirement matrix for each campaign and version it when firm-approved criteria change. Each row should identify the evidence category, the condition that makes it relevant, acceptable source types, the stage when it should be requested, and the person who can approve an exception.

The matrix might distinguish proof of product use, an identifying record, a dated treatment record, an employment record, or another campaign-specific item. Lawyers or authorized firm staff define these requirements. Intake staff and software can collect, organize, and report against them. They should not decide that a substitute proves legal sufficiency or that a missing record can be ignored.

Keep the requirement itself separate from the document that may satisfy it. One record may support several requirements. Several records may contribute to one requirement. A binary "documents complete" field hides both relationships.

For each requirement, define:

• the campaign and criteria version it belongs to
• the condition that activates it
• the request language approved for claimants
• accepted file or source categories
• the state transitions staff may use
• the reviewer role and exception path
• any approved time, access, or retention rule

Give every requirement an evidence state

Evidence state should describe what the team knows about a requirement, not how many files appear in an upload folder. Use states that lead to specific work.

Evidence state	Meaning	Next operational action
Not applicable	The configured condition did not activate the requirement	Retain the condition and criteria version that produced the state
Not requested	The requirement applies, but no approved request has been sent	Assign the request to an owner
Requested	A dated request was sent through a recorded channel	Wait until the due date or follow the approved cadence
Received, unclassified	A file arrived, but its document type and relationship are unconfirmed	Route it for classification
Classified, unreviewed	A proposed document type and claimant link exist	Route it to the permitted reviewer
Accepted for requirement	An authorized reviewer linked the source to the requirement	Preserve the reviewer, time, and decision basis
Exception	The file is unreadable, contradictory, incomplete, duplicated, or otherwise unresolved	Send it to a named exception queue
Unavailable	The claimant responded that the requested record cannot be obtained	Preserve that response and route the next decision to authorized staff

Do not collapse an unknown answer into an unanswered request. "I do not know which facility holds the record" is an explicit response. A request that received no response is unanswered. The first may call for a source-locating step or authorized review. The second may call for follow-up under the firm's approved cadence.

Track the request separately from the file

A request is its own record. Store the requirement, recipient, channel, message version, sent time, due date, delivery result, responses, reminders, and owner. A later upload should link back to the request without replacing its history.

Staff can see which requests are overdue, which messages failed to deliver, and which claimants replied without attaching the expected record. It also prevents a second upload from erasing the fact that the first file was unreadable.

Request state and evidence state can change at different times. A request may be closed while the received document still awaits classification. A requirement may return to requested after a reviewer rejects an unreadable file. Model both paths instead of forcing them into one status.

Preserve source provenance at arrival

Provenance begins when information enters the system. Record who supplied the item, how it arrived, when it arrived, which claimant and campaign it was associated with, and which original file was received. Preserve the original object and its stable identifier before conversion, extraction, or renaming.

The NIST Data Governance and Management Profile concept paper identifies accuracy, timeliness, completeness, relevance, and consistency as data-quality factors. It also notes that data from several sources or formats creates added challenges when provenance and lineage are uncertain. That general governance principle fits mass tort intake, where a questionnaire, call, portal upload, and later correction can all describe the same event.

The W3C PROV-O recommendation models provenance through entities, activities, and agents, including derivation and revision relationships. A law firm does not need to implement the ontology to use the operating idea. Keep the document as the entity, record classification or extraction as an activity, and identify the person or system responsible for that activity.

Classify without rewriting history

Document classification should add a proposed type and confidence state beside the original file. It should not rename an uncertain upload into certainty. A reviewer must be able to see the submitted file, the proposed classification, the rule or model version that produced it, and any later correction.

Store duplicates as relationships before deleting or merging anything. Exact file hashes can identify byte-for-byte copies. Similarity checks may flag scans, resaved PDFs, or overlapping page sets. A likely duplicate still needs a defined review path because two similar files may have different annotations, completeness, or source histories.

When staff confirm a duplicate, retain enough metadata to show which object became the maintained version and which sources supplied each copy. The firm's retention policy should decide what happens to redundant objects. A deduplication process should not make that policy silently.

Link proposed facts to pages

A document becomes operationally useful when a reviewer can move from a proposed fact to the source location that supports it. Store the document identifier, page or section, extraction method, proposed value, and review state with each fact. For image-only records, preserve the page image or coordinate reference used during review.

This structure matters when two sources disagree. A claimant may report one date while a record displays another. The system should show both values with their sources and send the contradiction to a reviewer. It should not choose the newest value, the most frequent value, or the output with the highest automated confidence as a legal conclusion.

Page-linked facts also make quality review specific. If a reviewer corrects a product identifier or date, the team can inspect the source and the process that produced the proposal. A detached value provides no comparable path.

Keep correction lineage

Corrections should create a new version rather than overwrite the earlier value. Record the prior value, corrected value, source, reason, person, timestamp, and downstream records affected. If the correction came from a later claimant statement, retain that statement as a source instead of labeling the new value as verified.

Use status terms carefully. "Reported," "extracted," "reviewed," and "confirmed under firm procedure" describe different events. None should imply that a legal issue has been decided. Authorized reviewers set the terms and decide which changes require attorney attention.

Apply access and audit controls by role

Mass tort intake can include personal, medical, employment, and dispute information. Access should follow the firm's roles and the current work. A document collector may need upload status without access to every extracted fact. A reviewer may need the source and correction history. Export and deletion authority may belong to a smaller group.

ABA Model Rule 1.6 addresses confidentiality for client information and reasonable efforts to prevent unauthorized disclosure or access. ABA Model Rule 1.18 addresses information learned from a prospective client even when no client-lawyer relationship follows. Firms must apply the rules of their jurisdiction and their own approved procedures.

The control catalog in NIST Special Publication 800-53 Revision 5 gives useful design questions for access enforcement, audit records, and information retention. It is not a law-firm checklist. Use it to test whether the system can restrict actions, record material events, protect that history from unauthorized change, and apply organization-defined retention periods.

Operate exception queues

An exception queue should group records by the action needed, not hide them under a general incomplete label. Useful queues include unreadable files, unclassified uploads, possible duplicates, missing required evidence, conflicting facts, failed requests, access questions, and retention holds.

Each exception needs an owner, reason, age, due date, permitted actions, and escalation route. The queue should also show the campaign and criteria version involved. That context prevents staff from resolving an old intake under a newly changed requirement without review.

Automation can flag, route, and assemble context. People retain decisions about evidentiary sufficiency, legal qualification, engagement, privilege, disclosure, and exceptions that the firm reserves for authorized staff.

Make retention a recorded decision

Retention is a policy decision, not a storage default. The firm should define how long to retain original uploads, derived files, duplicate copies, request history, declined or incomplete intakes, and audit events. Applicable duties, agreements, holds, and jurisdiction-specific rules may change those periods.

Store the policy or schedule version, the event that starts the period, any hold, the authorized decision, and the disposition event. Do not let a campaign closure, status change, or deduplication job trigger unreviewed deletion.

Hand off one governed record

The receiving case team should get the requirement matrix version, evidence states, original files, classifications, page-linked facts, correction history, request log, access context, open exceptions, and review decisions. The handoff should identify what remains missing and who owns it.

A review-ready file does not mean every possible record exists. It means the current evidence state is explicit, source-backed, and ready for the next authorized decision. Unknown facts remain unknown. Unanswered requests remain open or carry an approved disposition. No one has to reconstruct the collection history from email and filenames.

Book a demo →

A practical implementation sequence

Start with one campaign and one evidence category. Write the requirement matrix, configure its states, and test the full path from request through handoff. Include a missing response, an unavailable record, an unreadable scan, a likely duplicate, a contradictory date, and a corrected classification.

Review the result with intake staff, case managers, technical owners, and the lawyers responsible for the campaign. Confirm that each person can see the context needed for their role and cannot take actions outside it. Then add the next evidence category. This sequence keeps the operating model inspectable while the firm decides where automation belongs.