Tutorial ID | T-19 |
Section | Preparing a Case/Reviewing the case |
Title | Marking Events Before the Main Event Date |
Subtitle | Separate pre-existing baseline events from the consequences of the main event. |
Before You Begin
You have a case with a defined main event — an incident, injury — and records related to the event occurred both before and after it.
Event date — the date of the incident or injury the case is built around. It's the line everything else in the chronology is measured against, separating what came before from what the event caused.
What You Will Accomplish
By the end of this tutorial, every event in your case will be correctly marked as happening before or after the main event date. You will know how to fix a wrong or ambiguous main event date, distinguish pre-existing conditions from event-caused changes, and make sure the pre-event baseline is complete.
Why Does this Tutorial Matter
Case Chronology is built on the idea that a claim turns on a baseline what was before an event - the event itself - the change that follows.
Event is the line against which everything else is read. Events that happened before that date are a different matter from those that followed the event. Get this right, and the chronology demonstrates causation and the permanence of any change. Get it wrong, and pre-existing conditions and event-caused changes blur together.
What to Do if Something Goes Wrong
The list below covers the most common problems with marking pre-event and post-event entries. Each entry follows the same pattern: what you'll notice, why it likely happened, and how to fix it.
Tip Don't treat pre-existing events as noise to filter out. A well-documented "before" picture is often what makes the "after" credible — it shows precisely what changed. |
Problem: A pre-existing condition is presented as though the main event caused it.
Likely cause: A condition present before the event can be wrongly presented as caused by it.
Example: A patient had documented lower back pain for two years before a workplace fall.
After the fall, a chronology entry describes the ongoing back pain as an injury caused by the incident, without noting the two years of prior treatment that are already in the records.
Fix:
If it is stated in the report that the symptom is attributed to the main event, confirm that earlier records do not document the same symptom.
Distinguish a pre-existing condition from a change the event actually caused, based on what the records show — not on assumption.
Cross-check the date stated in the source records against the date set on the episode. The correct date on each episode is what determines whether a change counts as pre-existing or something the event caused.
Problem: The main event date itself is wrong.
Likely cause: If the anchor date is mistaken, every before-and-after classification built on it is wrong too.
Example: A case is opened with the main event date set to the date a claim was filed, rather than the actual date of the accident three weeks earlier.
Fix:
Confirm the main event date against several different types of records, not just one.
Click the three-dot icon in the upper-left corner of the screen.
Click Case details and find the Event date field.
Update the event date to match what the records show.
Once saved, the pre-event and post-event distribution updates immediately in the workspace.
Problem: A pre-existing condition that matters to the case gets buried among routine pre-event entries.
Likely cause: A case can accumulate dozens of routine pre-event entries — annual checkups, routine labs — and a significant condition becomes easy to skip.
Example: The main event is a fractured arm. Among the pre-event records sit dozens of entries for hypertension, hyperlipidemia, and routine vaccinations — none of it relevant to a fracture claim. A record of a prior fracture to the same arm, several years earlier is buried in that same pile. Because it's surrounded by so much unrelated routine history, it gets skimmed past along with everything else — even though it's the one entry that actually matters to the case.
Fix:
Review pre-event entries for anything relevant to the claim.
As you add each pre-event entry to the workspace, assess how significant it is and how much it could influence the event.
Problem: Event date is entered incorrectly — a post-event record appears as pre-event.
Likely cause: A typing mistake, a misread date on a scanned page, or a date pulled from the wrong part of a multi-page record can shift an event's date.
Example: A follow-up visit that took place three weeks after a car accident is entered with a date from the wrong page of a multi-page record, placing it a year earlier. It shows up in the pre-event portion of the workspace, as though the patient had already been receiving treatment for the same injury before the accident happened.
Fix:
When an event looks out of place, check its date against source records.
Click the three-dot icon in the upper-left corner of the screen.
Click Case details and find the Event date field.
Update the event date to match what the records show.
Problem: The case has no single, clear date for the main event, because the injury developed gradually rather than happening at one moment.
Likely cause: Some injuries — long-term exposure, repetitive strain, gradual poisoning from prolonged substance intake — don't have one obvious onset date the way an accident or a single incident does, so there's no clean line to mark "before" and "after" against.
Example: A patient develops symptoms of long-term chemical exposure at work. There's no single day the illness "started" — symptoms appeared gradually over several months. The case team decides to use the date of first documented medical complaint as the main event date, and notes that choice in the case record so later reviewers understand why that specific date was selected rather than an earlier or later one.
Fix:
Review the records for the earliest point when symptoms, exposure, or harm can reasonably be documented.
If the records support a range rather than a single date, choose a reference point — such as first diagnosis, first documented symptom, or last date of exposure — and use it consistently.
If you're working from an AI-generated report, add a comment noting the unclear event date, so other reviewers know to pay attention to it.
Summary
Every event in your case is now correctly marked as happening before or after the main event date, with the main event date itself confirmed against the source documents. Pre-existing conditions are distinguished from event-caused changes, and the pre-event baseline is complete and visible rather than missing or buried.