Can AI Build a Medical Chronology for an Injury Case?

Yes, as a first draft. AI can turn client medical records into a dated table with the event, provider and source page for each entry. You still verify every entry you will rely on against its cited page. Redact identifiers first, use a business plan that does not train on your content, and leave medical judgement to the expert.

A chronology is the best first job for AI in a personal injury file because its shape is simple (date, event, source) and its errors are checkable. The risk is not that the tool writes badly. It is that it writes a tidy, believable entry for a visit that happened a year earlier, or merges two appointments into one. A page-cited table puts each claim one click from its evidence, and that is what makes the draft usable.

Follow me on Instagram@sagnikteaches

What a litigation chronology needs that a records summary does not

A records summary tells you the story of the patient. A chronology prepared for a claim answers different questions: when did the symptom first appear, who recorded it, what did the client report at each contact, when were treatments started or stopped, were there gaps, and did anything in the records contradict the pleaded account. So the columns differ from a clinical timeline.

Connect on LinkedInSagnik Bhattacharya

The flag column does more work than any other. Defence arguments about causation often live in a pre-existing mention (an earlier back complaint, say) or in a gap between treatments, and you want both visible early.

Subscribe on YouTube@sagnikteaches

Before the upload: prepare the files

Records arrive as batches of PDFs from different providers, often scanned, often with the pages out of order. Preparation takes an hour on a 300-page file and prevents most downstream errors.

1. Combine and number. Merge the PDFs in one order and add a stamped page number across the whole bundle, so "p. 147" always means the same page.
2. Check the text layer. Select a sentence on three scanned pages. If the text does not highlight properly, run optical character recognition first and re-test. A bad text layer is the main source of garbled dates. The tutorial on AI extraction versus traditional OCR explains the difference.
3. Redact identifiers. Remove the client's name, date of birth, address and record numbers. Keep a key in your case system. Redaction before any upload covers the steps.
4. Split into chunks. Cut the bundle at provider boundaries, about 40 to 60 pages each. Smaller chunks reduce missed events. For reference, Claude's help centre says it analyses images and layout only in PDFs of 100 pages or fewer and processes text alone from 101 to 1,000 pages, so a 300-page bundle uploaded in one go would be read as text only, losing body charts, annotations and any page without a usable text layer.
5. Choose the plan. Use a business-tier assistant whose terms say it does not train on your content by default, in an account where you can delete conversations. A free personal account is not the place for health records.

300 pages for a road-traffic injury claim, in three passes

Say a small injury practice has a client with a neck and shoulder injury after a rear-end collision. The records run to 300 pages: 42 pages from the family doctor, 68 from the emergency department and imaging, 120 from a physiotherapy provider, 40 from an orthopaedic consultant, and 30 of pharmacy and miscellaneous letters. The partner wants a chronology by the end of the week.

Pass one: extract events chunk by chunk

You are building a medical chronology for a personal injury
solicitor. Use only the attached pages. For every dated clinical
event return one row:
Date | Provider | Event type | What the record says (factual, one
or two sentences) | Complaints reported | Page (stamped page
number from the bottom right) | Flag
Rules:
- Quote the record's wording for complaints, diagnoses and doses.
- If a date is unclear or missing, write "DATE UNCLEAR" and the
  page, never guess.
- Do not interpret, diagnose or comment on causation.
- Flag any mention of an earlier condition, a missed appointment,
  or a gap of more than 30 days between entries.
- Return rows in date order. At the end, list pages you could
  not read.

Run this on each chunk and paste the results into one sheet. For the emergency department pages the first output, in an illustrative extract, looked like this:

The pre-existing mention in the last row is exactly the kind of flag that saves a surprise later. Without the flag instruction, a summarising model drops it as irrelevant.

Pass two: merge, sort and find the gaps

Combine the chunk outputs into one sheet and sort by date in the spreadsheet, not in the AI tool, because sorting is something a sheet does exactly. Then ask the assistant to read the merged table (not the original records) and produce three lists: dates with more than one event from different providers, gaps over 30 days, and entries flagged "DATE UNCLEAR". In this case it found 412 rows, 7 unclear dates, 3 gaps (one of 54 days between the specialist referral and the first appointment) and 11 same-day clusters.

Pass three: the spot-check

This is the part that cannot be skipped. The method below takes about three hours on 412 rows and is the reason the chronology can be relied on.

1. Verify every row you will cite externally, in full: open the page, confirm date, provider, wording and page number. In this file that was the 38 rows that appear in the letter of claim and the expert instruction.
2. Sample the rest at 15 per cent, chosen by a random number column, not by choosing rows that look easy. That is about 56 rows.
3. Verify every flagged row: gaps, unclear dates, prior conditions. These are where mistakes cost most. Here there were 21.
4. Do a reverse read of 10 random pages: find the events on each page and confirm each is in the table. This catches omissions.
5. Record the error rate. If more than about 5 per cent of sampled rows have a material error (wrong date, wrong provider, wrong page, wrong wording), widen to full verification of that provider's pages and fix the prompt.

In this illustration the sample found 4 problems in 56 rows: two off-by-one page numbers where a page had been inserted, one date that read 12 March but was a letter's print date and the appointment was on the 19th, and one entry that said "referred for MRI" when the record said "MRI discussed, patient declined". The last one matters: it would have changed the narrative about mitigation. The fix was a prompt line, "report refusals and declined treatments as such", and a re-run on that provider's pages.

Where AI misreads medical records

• Dates. The record contains a letter date, a dictation date, an appointment date and a typed-up date. Ask for the clinical event date and tell the tool which to prefer. Day and month order in a document can be ambiguous, so check with sample rows.
• Abbreviations. "NAD", "c/o", "o/e" and "PRN" are common. The tool usually expands them correctly, but a rare abbreviation can be guessed. Ask it to keep the abbreviation and give the expansion in brackets.
• Negatives. "No evidence of fracture" reduced to "fracture evidence" is the classic summarising slip. Quote findings in the record's own words.
• Doses and drug names. Never accept an unverified dose. A transposed number is the difference between "10 mg" and "100 mg".
• Handwritten and faxed pages. Mark them as "human read" and read them yourself.
• Copy-forward notes. Electronic records carry forward text from a visit weeks earlier, so a complaint may appear at a later date that was not actually reported then. Flag identical wording across consecutive entries.
• Interpretation creeping in. "Symptoms consistent with whiplash" in a summary is your own or the model's opinion unless the record says it. Keep the table clean of opinion.

Further examples of prompts that earn their place

A consistency check against the client's account

Once the chronology is verified, paste in the client's statement (redacted) and ask: "Compare these statements with the chronology. List each statement the records support with the page, each they contradict with the page, and each the records do not address." A sample result: "Client says she could not lift her arm for three weeks: records at p. 163 (physio, 28 Feb) note 'active abduction to 90 degrees', which contradicts or at least qualifies this." That is a vulnerability you want to find before the other side does, and it is a question for the fee earner, not an automatic concession.

A one-page summary for the supervising partner

Ask for 200 words built only from verified rows, with a page reference after each sentence. Two quick rules: if a sentence has no page reference, delete it, and if the summary says "likely" or "appears", ask which row supports that.

A question list for the medical expert

From the flags column, generate questions for the expert: "The records show lower back pain at p. 13 in the year before the collision. Please comment on whether the lumbar symptoms from February onwards are attributable to the collision." You are asking the questions, and the expert answers them. The tool is just good at spotting which ones are worth asking.

A quick sum on time

A paralegal might spend 15 to 25 hours abstracting 300 pages by hand. In the illustration, preparation took 1 hour, extraction 1.5 hours including re-runs, merging 1 hour, and verification 3 hours, about 6.5 hours in total. The saving is real, but it is the extraction that is cheaper, not the checking. A firm that cuts the verification to save more time ends up with a document nobody can safely rely on.

A smaller case: 90 pages, a gap and a copy-forward trap

Take a second, illustrative file: a warehouse worker with a wrist injury after a fall from a pallet, and 90 pages of records from an occupational health service and a hand clinic. The same prompt runs in a single pass because the bundle is short. The merged table has 74 rows. Two things surface that a skim would miss.

First, a 47-day gap between the occupational health review (page 18) and the hand clinic's first appointment (page 31). Nothing in the records explains it. The flag does not say the client failed to attend. It says "no entries", and the fee earner asks the client why, which turns up a cancelled referral that the client did not know about. Second, three consecutive occupational health entries carry the sentence "reports ongoing numbness in ring and little finger". The first is dated 4 March. The next two are identical to the word. The prompt rule "flag identical wording across consecutive entries" marks them as probable copy-forward. The fee earner asks the clinician whether the numbness was reassessed at each visit, rather than quoting three reports of numbness as three separate observations in the letter of claim.

Handling DATE UNCLEAR rows

Unclear dates are not failures of the tool. Records often hold undated letters or entries that say "last week". The right treatment is a small routine.

1. Sort all "DATE UNCLEAR" rows into a separate tab with their page numbers.
2. Read each page yourself. Look for an adjacent dated entry, a header with a print date, or a fax stamp.
3. If you can place it, write the date with a note, such as "27 Feb (from fax header, p. 88)".
4. If you cannot, leave it undated at the end of the table and never put it in a letter as a dated event.

In the road-traffic example, six of the seven unclear rows were placed from fax headers. One stayed undated, and the fee earner asked the provider for a corrected copy.

The sums behind the spot-check

People ask why 15 per cent and why 5 per cent. These are working rules, not statistical guarantees, and it helps to know what they do and do not promise. If you check 56 rows at random and find 4 errors, the sample error rate is 4 in 56, about 7 per cent. Applied loosely to the roughly 300 rows nobody has opened (412 less the 38 cited rows, the 56 sampled and the 21 flagged, assuming no overlap), that suggests about 21 more errors in the unchecked part. That is why a sample result of 7 per cent is above the 5 per cent threshold, and why the response is to widen the check on the providers where errors clustered rather than to shrug. Had the sample found 1 error in 56 (under 2 per cent), you could reasonably stop. With small samples the estimate is rough, so use the numbers as a prompt to look harder, never as a certificate. And since every row used externally is checked in full, the sample protects the rest of the file, not the letter itself.

A verification log you can copy

Keep one line per chunk. An illustrative entry:

Case code: PI-0412 | Chunk: Physio part 1, p. 111-170 | Prompt v3
Run date: 12 Nov | Tool: business-plan assistant, account 1
Rows produced: 73 | Rows verified in full: 11 (cited in letter)
Random sample: 11 rows | Errors found: 1 (page off by one)
Flags verified: 5 of 5 | Reverse read: 3 pages, 1 omission added
Verified by: [initials] | Conversation deleted: 12 Nov

It takes a minute to write and answers the question every supervising partner eventually asks: how do we know this is right?

Where the chronology goes next

A verified chronology is the foundation for most other documents in the file. A demand letter draws on it, and AI demand letters for personal injury compares the tools for that job. For a broader view of what to hand over first, seven jobs to hand over first is a good map. If you are evaluating software that promises to do all this inside a case-management system, the buyer's checklist lists the questions that matter. Family lawyers working from events rather than records will find a similar structure in AI legal chronologies for family cases.

Choosing between a general assistant and a legal-specific product

Several vendors sell products built for medical-record review and chronologies, usually inside case-management or demand-drafting platforms. I haven't tested them, and a vendor's own accuracy claims cannot be compared with another's. What you can do is run the same test on any candidate: give it a file you have already chronologised by hand, count the entries it misses, count the entries it gets wrong, and see whether each entry links to its page. A product that links each row to the source page and lets you export the table has earned a longer trial. One that produces a polished narrative without citations has not.

For a firm with a few injury files a month, the workflow above with a general assistant, a spreadsheet and a verification log is likely enough, and the cost is the assistant's plan price plus your time. At higher volume, the argument for a dedicated product is the workflow around it rather than the extraction: intake from providers, a shared view for the fee earner and the paralegal, and a consistent output. Whichever you choose, the verification step stays.

Professional duties to settle before using it

A chronology is the work product of the firm. Before you use AI on it, settle four things in writing: whether your client care terms and your regulator's guidance allow the tool, what the client has agreed to (many firms add a sentence on the tools used with their records), who may use the tool and on which cases, and how long conversations are kept. Keep a short log for each case: date, chunk, prompt version, and who verified. If the chronology is ever challenged, the log shows that the work was done and checked by a person.

None of this changes the medical content, which belongs to the treating clinicians and your expert. The chronology records what the records say. It does not diagnose, attribute cause or value the claim, and any entry you cannot verify against its page does not go into a letter. Where privacy rules or professional guidance on health records are unclear for your firm, ask your regulator or a data-protection adviser before the first upload rather than after.

Medical chronology questions

Can AI read handwritten doctors' notes?

Only partly. Handwriting recognition on clinical notes is unreliable, and an error looks identical to a correct reading in the output. Mark handwritten pages for human reading, and never let a handwritten date or dose pass through an AI extraction unchecked.

Is a chronology the same as a medical summary?

No. A chronology is a dated list of events with sources. A summary is a narrative that interprets them. Build the chronology first and keep it free of opinion, then write the summary from it. Mixing the two hides which statements are evidence and which are your reading.

Should I give the AI the client's name?

Avoid it. Replace the name, date of birth and record numbers with a case code before you upload, and keep the key in your own system. The medical content still identifies a person in a small case, so use a business plan with no training on your content and check your obligations on health records.

How accurate does it need to be?

Every entry that you rely on in a letter, demand or expert instruction must be right, which means verified against the page it cites. Treat the AI draft as a finding aid, not as a source. An unverified chronology should never be quoted externally.

Further reads

• How to Summarise Bundles and Transcripts With AI Safely — Summarising long bundles and transcripts safely.
• Which Legal Tasks Should a Small Firm Never Hand to AI? — The line between drafting help and legal judgement.
• Personal Injury Lawyer Chatbot: Intake Questions, Limits and Cost — What an intake chatbot can and cannot do.
• ChatGPT or a Legal AI Tool: Which Should a Small Firm Use? — General assistant or legal tool: which fits a small firm.
• How Small Law Firms Use AI to Draft Letters and Routine Documents — Routine letters, with the same verification habits.
• AI for Divorce Lawyers: Turn Intake Notes Into a Case Chronology — Chronologies from intake notes rather than records.
• How to Redact Personal Data From Documents With AI Before Sharing — General steps for removing personal data from documents.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Claude help centre article on uploading files (PDF page limits); Claude pricing page (Team plan, no training on your content by default). Records, dates and figures in the examples are illustrative.