Mass Tort Intake Form Design: Fields, Logic, and Staged Collection

A mass tort intake form should collect the smallest useful set of case-specific facts at each stage, preserve the source and status of every answer, and route uncertainty to a person. It should separate unknown facts from unanswered questions, request evidence when relevant, and prepare a review-ready record without making conflict, qualification, engagement, or legal decisions.

Design the form around the next review decision

A useful mass tort intake form is not a long questionnaire copied across campaigns. It is the first structured representation of a prospective claimant, the alleged exposure or product use, important dates, relevant conditions, connected parties, available evidence, consent, and missing information.

Start by naming what an authorized reviewer needs at the next gate. The first stage may need enough identity and matter information to begin the firm's opening procedures. A later stage may need product identifiers, use dates, diagnosis details, or records that support a campaign-specific review. Each question should have an operational purpose and an owner for exceptions.

The ABA's intake and conflict-check overview identifies the prospective client, area of law, and general nature of a dispute as information commonly needed for conflict analysis. The form should support firm policy without asking for a complete life history before the firm knows whether it can proceed.

For every proposed field, document:

• the question shown to the person
• the business or review purpose
• the data type and allowed states
• when the field becomes visible
• whether it is required at that stage
• the permitted source, such as claimant answer, staff note, or document
• the person who resolves an exception
• the sensitivity, access rule, and retention rule

If the team cannot explain why a field is needed now, move it to a later stage or remove it.

Use staged collection instead of one exhaustive questionnaire

Staging reduces irrelevant collection and gives the intake team clearer work queues.

Stage	Collect or confirm	Hold for later	Exit condition
1. First contact	Identity, safe contact method, campaign source, broad matter category, basic party names, required notices	Detailed medical history, full document set, secondary damages	Record created, duplicate candidates shown, opening review ready
2. Campaign path	Firm-approved exposure or use questions, key dates, location, product or event identifiers	Questions unrelated to the answers already given	Relevant path completed or exception assigned
3. Evidence request	Documents tied to stated facts, upload source, received date, document type	Records that do not serve the current review gate	Required items received, unavailable, or assigned for follow-up
4. Quality review	Conflicts between answers and records, unknown states, corrections, missing fields	New legal conclusions or guessed values	Staff review complete or issue escalated
5. Authorized review	Structured facts, sources, evidence status, consent history, exceptions	Automated engagement or qualification decision	Authorized person records the permitted outcome

The W3C forms tutorial recommends dividing long forms into logical steps and informing users about their progress. For intake, each step should also save completed work, explain what comes next, and allow a person to return through a secure method. A session timeout should not force someone to re-enter a difficult account from the beginning.

Make conditional logic explicit and testable

Conditional logic should determine relevance, not legal merit. A prior answer can reveal the next appropriate question. It should not silently decide whether the firm will accept a matter.

For example, a campaign path may ask whether the person used a named product. If the answer is yes, the form can ask for the use period, location, prescribing provider, or available proof. If the answer is no, a different product or exposure path may appear. If the person is unsure, the record should enter an evidence or staff-review queue rather than being treated as no.

Store the logic as versioned rules that the firm approves. Each rule needs:

• a stable question identifier that does not change when display wording changes
• the answer or state that triggers the branch
• the questions shown, skipped, or deferred
• an effective date and campaign version
• a named approver
• a safe fallback when no condition matches

Test every branch with yes, no, unknown, unanswered, corrected, and conflicting-source scenarios. Also test what happens when the firm changes a rule while earlier intakes remain open. The record should retain the version used when each answer was collected.

Treat unknown, unanswered, and not applicable as different data

A blank field cannot explain what happened. It may mean the question was never displayed, the person skipped it, a connection failed, staff deferred it, or the person does not know. Those states create different next actions.

Use distinct values:

• Known: a person or source supplied a value.
• Unknown: the person was asked and could not provide the value.
• Unanswered: the question was presented but has no response.
• Not asked: logic or stage rules did not present the question.
• Not applicable: the question was reviewed and does not apply.
• Disputed: two sources or people provide materially different values.

Do not turn unknown into no. Do not use a placeholder date to satisfy a required field. An unknown product-use date may trigger a request for a pharmacy or purchase record. An unanswered date may trigger a reminder. A disputed date should show both sources to the reviewer.

These states should remain visible in exports and in the case record if the matter moves forward. Flattening them into empty cells during handoff recreates the ambiguity the form was meant to remove.

Validate accessibly without trapping the person

Validation should catch preventable format errors while allowing truthful uncertainty. Use an appropriate input type, a visible label, a clear example, and an explanation of why a detail is requested. Identify required fields in text and in programmatic markup. Keep keyboard focus predictable and do not use color alone to identify an error.

The W3C guidance on validating input recommends clear required-field labels, forgiving common input formats, accessible notifications, and server-side validation in addition to browser checks. Applied to mass tort intake, that means accepting familiar phone and date formats, normalizing them after entry, and returning a specific correction message instead of deleting the person's work.

An error message should name the field, explain the problem, and state how to fix it. Put an error summary before the form and link each item to the affected control. Preserve valid answers when another field fails. Test the complete path with keyboard navigation, screen readers, zoom, mobile layouts, slow connections, and realistic file uploads.

Validation rules also need an exception path. A person with no stable address, an uncertain date, a name that does not fit a narrow pattern, or a document larger than the upload limit still needs a way to continue or request help.

Collect only what the current stage requires

Mass tort intake can involve health, employment, financial, identity, and family information. More collection is not automatically better intake. It increases review work and expands the information the firm must govern.

The ABA comment on Model Rule 1.18 advises limiting an initial consultation to information that reasonably appears necessary to decide whether to undertake the matter. The applicable rules in each jurisdiction and the firm's own counsel control. Form designers should translate the approved boundary into stages, notices, access controls, and stop points.

The FTC's guide to protecting personal information similarly recommends knowing what information enters the business, tracing where it goes, limiting collection and retention to a legitimate need, and restricting access. A field inventory should therefore identify where each value is stored, who can see it, how long it remains, and what happens to incomplete or declined inquiries.

Record consent as an event, not a checkbox snapshot

Keep operational permissions separate from engagement. Consent to receive text reminders, submit records, use an electronic signature, or authorize a specific records request may occur at different times. The form should present firm-approved wording and record the text version, action, timestamp, channel, person, and any later withdrawal.

Do not preselect consent controls or combine unrelated permissions into one required choice. Explain whether submitting information creates a prospective-client communication, whether the firm has accepted representation, and how urgent deadlines should be handled, using wording approved for the relevant jurisdiction and workflow.

Software can store the event and enforce a communication preference. A lawyer or authorized firm representative remains responsible for the legal effect of a notice, consent, engagement, or withdrawal.

Carry documents and provenance into the review record

An upload is not complete merely because a file reached storage. Attach it to the correct intake, preserve the original, record who supplied it and when, classify it, and show its processing state. If a value is extracted from a record, connect the proposed fact to the file and relevant page or passage.

The review record should distinguish claimant statements, staff notes, document-derived values, calculations, and approved facts. When sources conflict, retain each value. Do not overwrite the earlier answer with the newest one.

A correction record should show:

• the prior value and its source
• the proposed or approved new value and its source
• who made or approved the change
• when the change occurred
• why the correction was made when that reason matters
• which downstream review or export received the corrected value

This history gives a reviewer enough context to resolve discrepancies and lets operations staff find fields or document types that repeatedly need repair.

Build the human review queue before launch

Every rule needs a named exception owner. Create queues for likely duplicates, missing evidence, conflicting values, inaccessible uploads, unsupported answers, consent issues, and records that reached the end of logic without a valid next state. Each item should show its age, source, current owner, and permitted action.

Before launch, run synthetic or properly authorized test records through every stage. Include interrupted sessions, changed answers, duplicate identities, unknown dates, two documents with different values, and corrections made after review. Confirm that no automatic path resolves a conflict, qualifies a claim, forms an engagement, gives advice, or creates a legal conclusion.

Book a demo →

The form is the first governed case structure

A mass tort intake form succeeds when it produces a review-ready record rather than a completed-looking questionnaire. The record should show what the person reported, what the evidence supports, what remains unknown, which questions were not answered, which rule version applied, and who owns the next decision. That structure can move into case management without re-keying or losing the source history behind it.