Mass Tort and MDL Case Management Software: What Happens When 12,000 Claimants Reach Settlement At Once?

Why mass tort volume breaks systems built for single plaintiff work

A firm signs 900 claimants in a quarter off television and social spend. Three marketing vendors deliver lead files with different column names, and about 60 of those claimants appear in two files because two vendors bought from the same aggregator. Each one needs a retainer, a HIPAA authorization, proof of product use or exposure, and medical records from an average of four providers who take between six weeks and eight months to respond. Meanwhile a plaintiff fact sheet deadline in one MDL applies per claimant, and the case management order counts in days, not business days.

Two years later that docket settles on a points grid. Now someone has to compute, per claimant, a gross allocation from injury tier and exposure duration, subtract a common benefit assessment, subtract attorney fees split with three referring firms on different arrangements, subtract case costs advanced, subtract a Medicare conditional payment demand, a state Medicaid lien, an ERISA plan reimbursement claim and a hospital lien, then produce a disbursement statement the claimant will read line by line. Multiply by 12,000. If any of that math lives in a workbook, the exposure is not theoretical. Lien resolution errors and misallocation follow a lawyer personally.

What Litify, Filevine, Neos and SmartAdvocate actually leave you doing

All four are credible and plenty of successful firms run on them. SmartAdvocate and Assembly Neos are strong personal injury case management systems with mature intake and medical tracking. Filevine has the best document assembly and templating of the group. Litify carries the Salesforce platform behind it, which means real reporting and a genuine automation layer.

The shared limit is the unit of work. All four are built around a matter with a plaintiff attached, and mass tort inverts that: you have one claimant who may sit in three dockets, and one docket holding tens of thousands of claimants who must be evaluated against criteria that change when the special master issues a new order. Qualification lives as custom fields and checklists rather than as a versioned rule set you can re run across the whole inventory when the criteria move. Records retrieval is tracked as tasks rather than as a chase pipeline with per provider behaviour. And none of them resolve liens or run settlement allocation, so at the exact moment your exposure peaks, the work leaves the system and lands in a spreadsheet and a lien vendor's portal. Litify inherits Salesforce economics too, so growing your claimant count and your user count are both billable events.

Problem 1: intake arrives dirty, at volume, from people you do not control

Vendor files come as CSV, as portal exports, as a nightly push with names spelled three ways and dates of birth missing. The same claimant gets sold twice. Some records have a signed retainer already, some have a recording of a call, some have nothing but a phone number. If two vendors both claim a claimant, you have a fee dispute waiting.

A build treats intake as an ingestion pipeline with a claimant as the persistent identity, not a lead. Fuzzy matching on name, date of birth, phone and address flags probable duplicates before either record advances, and the system records which vendor delivered first with a timestamp you can defend. Retainer and authorization execution runs through e-signature with the signed artefact attached to the claimant, so the answer to whether you are engaged is a field, not an email search. Every vendor gets a scorecard: signed rate, qualification rate, cost per qualified claimant. Some vendors are worth three times what you pay and some are selling you rejections, and until you measure per vendor you are buying both at the same price.

Problem 2: qualification criteria change and you cannot re run the inventory

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 as in the Camp Lejeune claims. Criteria then move, because a court narrows a class or defence counsel challenges a proof standard. If your criteria are checkboxes on a form, moving them means a paralegal reopening 8,000 files.

What a build does: express qualification as a versioned rule set per tort, evaluated against structured evidence fields, producing a status and a reason per claimant. When the criteria change you publish version four and the whole inventory re evaluates overnight, with a report showing exactly who moved from qualified to needs review and why. That report is also what you hand co counsel and what you defend if a claimant challenges a decline. Nothing in a general case management system does this, because nothing in single plaintiff practice needs it.

Problem 3: medical record retrieval is a supply chain, not a task list

The bottleneck in every mass tort is records. A claimant names four providers, each with its own release requirements, its own copy service, its own turnaround, its own invoice. Requests go unanswered, authorizations expire, providers demand a fresh HIPAA form because the last one is over a year old, and one hospital system routes everything through a third party that charges per page.

Treat it like procurement. 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. Requests get a chase schedule with automatic follow up, authorizations carry an expiry that triggers re execution before it lapses, and costs are captured per claimant because they are recoverable at disbursement. When records land, extraction pulls diagnosis dates, procedure dates and provider names into the structured evidence fields the qualification rules read, so the file advances without a human reading 400 pages to find one date. That is the single most valuable automation in the category.

Problem 4: fact sheets have per claimant deadlines across several courts

A plaintiff fact sheet is a court ordered document with a format specific to that MDL and a deadline that runs per claimant from a triggering event, usually service or a census registration. Miss enough of them and you draw a show cause order and dismissals with prejudice. Tracking them in a shared calendar across three dockets does not scale past a few hundred.

A build generates the fact sheet from claimant data already collected, flags the fields still missing before the deadline rather than on the day, tracks service and defence deficiency notices as first class objects with cure deadlines, and maintains a per docket dashboard your case operations director can read in one screen. Deficiency notices in particular deserve their own workflow, because they arrive in batches and each one restarts a clock.

Problem 5: settlement is where the real liability sits

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 those per page record charges. Then liens: Medicare conditional payments, Medicaid, ERISA and private plan reimbursement, hospital and provider liens, sometimes child support. Each has its own resolution track and its own final demand letter, and a claimant cannot be paid from the qualified settlement fund until they are all closed or held back.

What a build does: model the waterfall as data with a version per settlement programme, keep lien status per claimant per lien type with the demand documents attached, enforce that disbursement cannot be released while an open lien lacks a holdback, and generate the claimant facing settlement statement from the same numbers that drive the payment file. You still use a lien resolution vendor. You stop being unable to answer, at any moment, how many claimants are payment ready and what is blocking the rest.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, mass tort platforms price like this. A first release covering vendor intake with deduplication, the qualification rule engine, and the records retrieval pipeline runs $70,000 to $150,000 and ships in 14 to 20 weeks. Adding fact sheet generation, lien workflow, settlement allocation and a co counsel portal takes the total to $220,000 to $500,000 across 8 to 14 months.

What drives cost up: the number of concurrent dockets, because each has its own criteria, fact sheet and settlement grid. Co counsel access, since scoped visibility across firms is a permissions model with real consequences. Volume itself, because a system holding 40,000 claimants with 60 documents each has genuine architecture requirements around storage, search and reporting that a 2,000 matter firm never encounters. And migration off an incumbent, which is heavy when documents run to terabytes.

What keeps cost down: building for your largest active docket first and generalising after, rather than designing an abstract mass tort platform on day one. The second docket is where the model earns its keep and the first is where it gets learned.

Build versus buy, and when buying is right

Buy if you run under roughly 1,000 claimants on a single docket alongside a standard personal injury practice. SmartAdvocate or Neos will handle it, and a custom build would be a distraction from signing cases. Buy if your mass tort work is referral out, where you sign and refer for a fee and never own qualification or settlement.

Build when two or more apply. You hold more than 5,000 claimants, or you are across two or more dockets with different criteria. Your last settlement required an ops person to build allocation in Excel and you have not stopped thinking about it. You co counsel with firms who need scoped visibility and currently get spreadsheets by email. Your marketing spend is large enough that per vendor qualification economics would change your buying. Or your qualification criteria have moved once already and re running the inventory took weeks of paralegal time.

How to choose a developer

Ask them to whiteboard the data model first. 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. A developer who draws a matter with a claimant field has built personal injury software and will hit the wall at 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. Ask how they would enforce that no disbursement releases with an unresolved lien and no holdback, because that is the control that protects you personally. Ask what document volume they have actually handled, in terabytes and in documents per record, not in customer logos.

Ask who owns the code and settle it before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. In a practice where a system holds the qualification history of tens of thousands of claimants, a vendor who controls that data controls your docket.