Most personal injury firms run demands and medical records in two different places. Records live in the case management system, where they are stored and named. Demands get built somewhere else, usually by a person reading those records and assembling a document by hand.
That split is the single largest source of delay in pre-litigation. The bridge between the two systems is a person, and that person’s reading time sets the firm’s throughput ceiling.
This guide covers what each function actually requires, why most firms ended up with them separated, and what changes when the reading and the drafting happen in the same place.
Every case management system stores medical records. Far fewer read them.
Storage means the PDF is attached to the matter, named, and retrievable. That is a filing capability, and it is genuinely useful. But a stored record contributes nothing to the demand until a human opens it, reads it, and extracts what matters.
Reading means the system parses the record into structured data: providers, dates of service, diagnoses, procedures, and charges. Once that structure exists, the software can build a medical chronology, reconcile bills against treatment, flag a treatment gap, and identify a provider referenced in one document whose records never arrived.
The distinction shows up in one question: can the system tell you something is missing? Absence is invisible to a filing cabinet. A system that read the records knows a bill exists for a visit with no corresponding treatment note.
Streamline case prep and strengthen damages narratives. See how EvenUp’s MedChrons help maximize settlement outcomes.
Download Now
Demand functionality also splits into two very different things, and this is the distinction that most often gets lost in a vendor conversation.
Template-based generation merges case data into a document skeleton. The firm’s name, the client’s name, the dates of loss, the damages total. Fields the system already holds get dropped into predetermined slots.
This is what most case management systems mean when they advertise demand automation, and it is a real convenience. It saves formatting time, enforces consistent structure, and removes the tedium of rebuilding a document shell for every case.
What it does not do is produce substance. The treatment narrative, the causation argument, the account of how the injury changed the client’s life: every one of those still requires a person to read the file and write it. The template determines where the substance goes, not what it says.
Record-based generation builds the demand from the extracted case file. The treatment narrative comes from the parsed chronology. The damages figures come from reconciled bills. The exhibits come from the source documents, with citations pointing back to the page each fact came from.
The difference is where the substance originates. Template generation produces a formatted document a person then fills with substance. Record generation produces substance a person reviews and refines.
That distinction determines what the software actually saves. A firm that adopts template automation and expects reading time to fall will be disappointed, because the reading was never the part the template touched. The mechanics of building the document either way are covered in the guide on how to write a personal injury demand letter.
Ask where the treatment narrative comes from. If the answer describes fields a person completes, it is template generation. If it describes the medical records themselves, it is record generation.
A second question settles any ambiguity: load a case with records attached and nothing else, then ask what the system produces. A record-based system returns a populated draft. A template-based system returns a skeleton waiting for input.
Demands don’t just tell a story, they build a case. See how EvenUp demands provide a 69% higher likelihood of tendering policy limits.
Download Now The split is a historical accident rather than a design decision.
Case management systems were built as databases, and databases were the right answer to the problem firms had twenty years ago: files scattered across physical folders and individual desktops. Those systems solved storage, and they solved it well.
Demand production was never a database problem. It required reading, judgment, and writing, so it stayed with people, and the software that eventually addressed it was built separately by different vendors solving a different problem.
The result is the arrangement most firms run today. Records in one system, demands produced by a paralegal reading from that system into a Word document. This is also why buying a better case management system rarely changes time-to-demand: it improves the storage half of a problem whose cost sits in the reading half.
Four things change, and they compound.
Usually not. The case management system is the system of record, holding the matter, deadlines, contacts, and billing, and replacing it is a disruptive project that often stalls adoption.
The more practical path is adding a layer that reads records and generates demands on top of the system of record you already run, connected by integration rather than migration. What matters is that the reading and the drafting happen in the same place. Whether that capability lives inside your CMS or in a connected platform is an architecture decision, and the broader evaluation is covered in the guide on choosing PI case management software.
EvenUp handles both sides.
Because both functions run on the same extracted data, a record arriving in month four updates the chronology and the demand draft together, and the firm connects it to the case management system it already uses rather than migrating off it.
Lerner & Rowe Injury Attorneys save three months per case on pre-litigation work, which is where the reading and assembly time actually sits.
Scaling case volume used to mean adding staff or letting strategy slip. Lerner and Rowe on doing neither. Fifty three minutes.
Watch Now
The question of which system handles demands and records has a straightforward answer for most firms today: two systems do, and a paralegal connects them. That arrangement works, and it also sets a hard ceiling on how many cases a firm can move, because the bridge is human reading time and reading time does not scale.
Whether you consolidate onto one platform or connect a records-and-demands layer to your existing system of record, the capability to look for is the same. The software should read the records rather than hold them, and the demand should come out of what it read.
Schedule a call to see how EvenUp handles both on one of your real cases.
Most firms use a case management system for record storage and produce demands separately, with a paralegal reading the records and assembling the document. Unified platforms handle both by parsing records into structured data and generating the demand from that data, so the reading and the drafting happen in one system.
Many can generate a demand from a template by merging case data into a document skeleton. Fewer can generate one from the medical record itself, which requires parsing the records into structured data first. The difference determines whether the software saves formatting time or reading time.
Template generation drops fields a person completed into predetermined slots, producing a formatted document that still needs substance written into it. Record generation builds the treatment narrative and damages figures from the parsed medical records, producing substance a person reviews.
Storing means the file is attached to the matter and retrievable. Reading means the system extracts providers, dates of service, diagnoses, and charges as structured data. Only a system that reads records can build a chronology, reconcile bills, or tell you a document is missing.
Usually not. Many firms add a layer that reads records and generates demands on top of their existing system of record, connected by integration. The requirement is that reading and drafting happen in the same place, not that everything runs on one vendor.
Upload a case with records attached and nothing else, then see what the system produces. A system that reads records returns a populated timeline or draft. A storage system returns an empty structure waiting for input.
