Mass Tort Case Management Software Problems: The 5 That Surface at Settlement, and How to Avoid Them

Why does qualification get built as checkboxes and then need rebuilding?

Because the first docket looks simple. A tort qualifies on specifics: a product identified by manufacturer and lot period, an exposure window with dates, a diagnosis inside a date range, sometimes a surgery, sometimes a residency period. Somebody builds a form with those fields, a paralegal ticks them, and the intake team calls it qualification. For the first 400 claimants that is genuinely adequate.

Then the criteria move, which they always do. A court narrows the class. Defence counsel challenges the proof standard for exposure. Your own case evaluators tighten a diagnosis window after seeing what survives. Now every one of those 8,000 checkbox files has to be reopened by a human, and the answer to how many claimants moved from qualified to needs review is a number somebody assembles by hand over a fortnight.

The design that survives is a versioned rule set per tort, evaluated against structured evidence fields, producing a status and a reason per claimant. Publish version four and the whole inventory re-evaluates overnight, with a report showing exactly who moved and why. That report is what you hand co counsel, and it is what you rely on when a declined claimant challenges the decision. Nothing in single plaintiff practice needs this, which is why nothing in single plaintiff software provides it, and why a firm that scoped its mass tort system as a personal injury system with extra fields ends up rebuilding the core in year two.

What goes wrong with duplicate claimants and vendor intake files?

Intake at volume arrives dirty from people you do not control. Three marketing vendors deliver files as CSV, as portal exports and as a nightly push, with names spelled three ways and dates of birth missing. Some records carry a signed retainer, some a call recording, some nothing but a phone number. And a proportion of them are the same human, because two vendors bought from the same aggregator.

Duplicates are not a data hygiene irritation, they are a fee dispute and a client confusion problem. Two intake specialists call the same person, two vendors invoice for the same claimant, and if the case advances nobody can say which vendor delivered first. The failure surfaces months later at reconciliation, when the evidence you need is a timestamp nobody recorded.

Treat intake as an ingestion pipeline where the claimant is the persistent identity rather than the lead. Fuzzy matching on name, date of birth, phone and address flags probable duplicates before either record advances, and delivery order is stamped with a timestamp you can defend. Retainer and authorization execution runs through e-signature with the signed artefact attached to the claimant, so whether you are engaged is a field rather than an email search. Then score every vendor on signed rate, qualification rate and cost per qualified claimant, because some vendors are worth three times what you pay and some are selling you rejections at the same price.

Why do records retrieval and e-signature integrations break after launch?

Because records retrieval is not an integration, it is a supply chain, and it gets built as a task list. A claimant names four providers. Each has its own release requirements, its own copy service, its own turnaround measured anywhere from six weeks to eight months, and its own invoicing habits. One hospital system routes everything through a third party charging per page. Requests go unanswered. Authorizations expire and the provider demands a fresh HIPAA form because the last one is over a year old.

A task list models none of that. What works is procurement thinking. Every provider becomes a record with observed behaviour: average days to respond, refusal patterns, whether they accept electronic requests, whether they invoice before or after delivery. Requests carry a chase schedule with automatic follow up. Authorizations carry an expiry that triggers re-execution before it lapses rather than after a provider rejects it. Costs are captured per claimant because they are recoverable at disbursement, and a firm that does not capture them loses real money quietly across thousands of files.

The e-signature side breaks for a duller reason: retries and duplicates. A resent authorization creates a second envelope, both come back signed, and the claimant file now holds two documents with different dates. Insist that every outbound envelope is idempotent against the claimant and document type, and that the system reconciles what was sent against what came back rather than trusting a webhook that fired once.

What happens when lien resolution and settlement allocation are left out of scope?

They leave the system, and they leave it at the exact moment your exposure peaks. Allocation is a waterfall and every layer has an owner who will check it. Gross award from the grid, common benefit assessment, fee split across referring and co counsel firms on differing agreements, advanced case costs including per page record charges, then liens: Medicare conditional payments, Medicaid, ERISA and private plan reimbursement, hospital and provider liens, sometimes child support.

A claimant cannot be paid from the qualified settlement fund until each of those is closed or held back. Do that math in a workbook across 12,000 claimants and the exposure is not theoretical, because lien resolution errors and misallocation follow a lawyer personally rather than the firm.

Model the waterfall as data with a version per settlement programme. Keep lien status per claimant per lien type with the demand and resolution documents attached. Enforce, in software, that a disbursement cannot release while an open lien lacks a recorded holdback. Generate the claimant facing settlement statement from the same numbers that drive the payment file, so the statement the claimant reads line by line and the money that moves cannot disagree. You will still use a lien resolution vendor for the negotiation itself, which is a specialist service rather than a feature. What you stop doing is being unable to answer, at any moment, how many claimants are payment ready and what is blocking the rest. Confirm your specific obligations with lien counsel, since they vary by plan and by state.

Should you build custom or configure what you already own?

Plenty of firms should not build. If you run under roughly 1,000 claimants on a single docket alongside a standard personal injury practice, SmartAdvocate or Assembly Neos will carry it, and a custom build is a distraction from signing cases. If your mass tort work is referral out, where you sign and refer for a fee and never own qualification or settlement, buy and move on.

Be fair to the incumbents at the top end too. Filevine has the strongest document assembly and templating of the group. Litify carries the Salesforce platform behind it, which means real reporting and a genuine automation layer, though it also inherits Salesforce economics so claimant growth and user growth are both billable events. All four are credible products and successful firms run on them.

The shared limit is the unit of work. All of them are built around a matter with a plaintiff attached, and mass tort inverts that: one claimant may sit in three dockets, and one docket holds tens of thousands of claimants evaluated against criteria that change when the special master issues a new order. Build when two or more apply: you hold more than 5,000 claimants, you are across two or more dockets with different criteria, your last settlement required an operations person to rebuild allocation in Excel, you co counsel with firms who currently get spreadsheets by email, or your qualification criteria have already moved once and re-running the inventory cost weeks.

How do hidden costs get into the quote?

Five sources, and each is a question you can ask before signing.

• Concurrent dockets. Each carries its own criteria, fact sheet format and settlement grid. A quote written against one docket becomes a change order when the second one signs.
• Co counsel access. Scoped visibility across firms is a permissions model with real consequences, and retrofitting cross firm visibility onto a system that assumed one firm is genuinely expensive.
• Document volume. A system holding 40,000 claimants with 60 documents each has architecture requirements around storage, search and reporting that a 2,000 matter firm never meets. Ask what volume the team has actually handled, in terabytes and documents per record.
• Migration. Moving off an incumbent when medical records run to terabytes is heavy, and it runs alongside launch rather than blocking it.
• Rule agreement. The most common schedule slip is not engineering. It is that a firm's intake team and its case evaluators apply different standards for the same tort, and the build cannot encode a rule those two still argue about.

In Digital Heroes delivery experience a first release covering vendor intake with deduplication, the qualification rule engine and the records pipeline runs $70,000 to $150,000 over 14 to 20 weeks, with the full platform at $220,000 to $500,000 across 8 to 14 months.

What separates a build that works from one that fails here?

Make them whiteboard the data model before anything is signed. The right answer separates claimant, docket participation, evidence and settlement position as distinct things, because one human can be a claimant in three torts with different qualification states in each. A developer who draws a matter with a claimant field has built personal injury software and will hit the wall somewhere around claimant number 3,000.

Ask specifically how they would re-run qualification after criteria change, and listen for versioned rules rather than a data migration script. A migration script means the answer to what changed is a diff nobody can read to a judge.

Ask how they would enforce that no disbursement releases with an unresolved lien and no holdback. That is the control that protects you personally, and it should be a hard constraint in the system rather than a report somebody checks.

Build for your largest active docket first and generalise afterwards, rather than designing an abstract mass tort platform on day one. The first docket is where the model gets learned and the second is where it earns its keep. And settle ownership of the code and the cloud accounts before kickoff, in writing, because a system holding the qualification history and settlement position of tens of thousands of people gives whoever controls it a hold over your docket at the moment you can least afford a dispute.