Tutorial ID | T-09 |
Section | Evidence Processing |
Title | Adding Important Events and Dates From Documents |
Subtitle | Turn key pages into a dated, sourced record of events without misreading a date or missing one. |
Before You Begin
You have a set of key pages selected and organized for detailed review.
You know which events and dates the case's chronology needs to capture.
What You Will Accomplish
By the end of this tutorial, every event you add will be tied to the document it came from, dated correctly and unambiguously, free of duplicates, and clearly marked as either a documented finding or a reported complaint.
Why Does This Tutorial Matter
The chronology is the spine of a case. Once the key pages are in front of you, the work is to turn what they contain into a structured record of events — what happened, and when — that the analysis and the report will rest on.
A single misread date can move an event in the sequence and change the story the case tells, and a missed event can leave a hole no later step will fill. Getting this right matters more than almost anything else, because everything downstream — the timeline, the report, the argument — is built on top of it.
Steps
Link every event to its source — add events as you find them and tie each to the page it came from.
Check dates against the document — read dates carefully from the source, since a misread date moves an event in the timeline.
Separate when it happened from when it was recorded — where the two differ, capture the right one for the event.
Cross-check for missed events by comparing against the key pages, so nothing important is left out of the record.
Confirm an event isn't already recorded from the same document before adding it, to avoid duplicates.
Verify AI-extracted events against the source, exactly as you would any other AI-generated content.
Note A date is not a detail. In a case where sequence drives causation, a date read wrongly does not just misplace one event — it can change what appears to have caused what. |
Tip When you add an event, capture enough context to make it stand on its own later — what happened, the date, the provider, and the page behind it. An event you can trace is an event you can defend. |
What to Do if Something Goes Wrong
The list below covers the most common problems when adding events and dates. Each entry follows the same pattern: what you'll notice, why it likely happened, a real example, and how to fix it.
Problem: An event appears out of sequence, or the clinical story doesn't quite make sense once the timeline is assembled.
Likely cause: A date of service, date of injury, or report date was misread from a scan, especially a handwritten or stamped one, placing the event in the wrong order.
Example: A date read as 3/4/2023 from a handwritten note was actually 8/4/2023, and the resulting chronology shows a follow-up visit happening before the injury it followed.
Fix:
Confirm each date against the source document rather than accepting a transcribed value.
Take particular care with handwritten and stamped dates, which are the most error-prone.
Check that the resulting sequence makes clinical and factual sense — an event out of order is often a misread date.
Problem: An event is recorded with a vague or partial date, and it's unclear exactly when it happened.
Likely cause: The source record used a relative reference, such as “two weeks later” or “at follow-up,” rather than giving an actual date, and it was entered as-is or guessed at.
Example: A note reading “seen again two weeks later” is entered into the chronology with a guessed date, when the actual date could have been calculated from the visit it refers back to.
Fix:
Resolve relative references to actual dates using the surrounding records.
Where a date can't be fixed precisely, record it as approximate rather than guessing a specific day.
Note the basis for any inferred date so it can be checked.
Problem: A date in the chronology doesn't match the date on its source document once you check the convention it was written in.
Likely cause: A date such as 03/04 was read using the wrong convention — month/day versus day/month — and medical-legal records often mix conventions.
Example: A record using day/month order lists 03/04 meaning April 3rd, but it's entered into the chronology as March 4th.
Fix:
Confirm the date convention used in each source before entering the date.
Use an unambiguous format in the chronology so entries can't be misread later.
Flag any date whose convention you couldn't confirm.
Problem: An event in the chronology has no link back to the document that supports it.
Likely cause: The event was added without attaching a source reference at the time, so it can't be verified later.
Example: A chronology entry describes a diagnosis with no back-reference, and a reviewer has no way to confirm which document it came from.
Fix:
Attach the source reference to every event as you add it.
Confirm the reference points to the page that actually records the event.
Treat any event without a reference as unconfirmed until one is added.
Problem: The same event appears more than once in the chronology.
Likely cause: The same event was recorded in more than one document, and each mention was entered as if it were a separate occurrence.
Example: A hospital admission described in both an intake form and a discharge summary is entered into the chronology twice.
Fix:
Run duplicate detection before and during event entry.
Check whether a seemingly new event is the same one recorded in another document.
Record each event once, citing the documents that support it.
Problem: A reported complaint and a documented diagnosis are entered into the chronology as if they carry the same weight.
Likely cause: The event wasn't checked for whether it reflects a claimant's reported history or an actual documented clinical finding.
Example: A patient's reported onset of pain is logged in the chronology with the same phrasing as a confirmed diagnosis, and a reader can't tell the two apart.
Fix:
Distinguish events that are documented findings from those that are the patient's reported history.
Word each event so its nature and source are clear.
Keep reported and documented onset dates separate where they differ.
Problem: A period where you'd expect treatment or records has nothing in the chronology, and no one has flagged it.
Likely cause: Only the events present in the records were added, without checking for periods where an event should exist but doesn't.
Example: A six-month gap between two treatment episodes goes unremarked in the chronology, leaving the reader to assume continuous care that may not have happened.
Fix:
As you build the chronology, watch for gaps where you'd expect an event and find none.
Determine whether a gap reflects no treatment or simply missing records.
Note significant gaps explicitly rather than letting the chronology imply continuity.
Summary
Every event in the chronology now has a confirmed date, a clear source reference, no duplicate, and a clear label distinguishing a documented finding from a reported complaint — with any real gap in the record noted rather than glossed over.