How AngelTrack uses patient checkpoints to turn a patient's medical history into a timeline.
AngelTrack stores patient data as a series of checkpoints, showing the patient's demographic and billing information as it changes over time. Each week a new checkpoint is taken, applying to all patient interactions for that week.
Here is an example:
| John Doe | |
|---|---|
| Global Data (appears in all runs) | Checkpointed Data |
|
Checkpoint 1 (Jan 1-Jan 7)
|
Checkpoint 2 (Jan 8-Jan 14)
|
|
Checkpoint 3 (Jan 15-Jan 22)
|
|
Checkpoint 4 (Jan 23-Jan 30)
|
|
|
And so on... |
The global data -- in the left-hand column shown above -- is the information that never changes. Or if it does change (such as when correcting a mistake), the change applies retroactively to every one of the patient's dispatches.
The checkpointed data -- in the right-hand column -- is everything that does change over time. A separate copy is stored for every week that the patient was seen. Changes to the information during that week are not applied to patient interactions prior to that week... but changes are carried forward into the future.
Why are drug allergies checkpointed?
You may be wondering why the "Drug allergies" field is checkpointed, even though drug allergies typically don't change over time.
The reason why is because although the drug allergies themselves don't change over time, the crews' knowledge of them does. On the first visit, the drug allergy data may be unavailable, and so the crew does not know what allergies the patient has. If that data becomes available during a later visit, it will be stored in the later checkpoint rather than being stored globally, so as not to contradict the first crew's medical decisions unnecessarily. They might've administered a medication that was only later discovered to cause an allergic reaction.
A Checkpoint Every Monday
Each checkpoint applies to a one-week period starting Monday morning and ending seven days later (Sunday night). A checkpoint is collected for a given week if the patient is seen at any time during that week. The created checkpoint then applies to any other visits for that patient the same week.
Checkpoints are also taken every January 1st and July 1st, no matter what day of the week it lands on, because insurance coverage frequently changes on those dates. So, a patient seen several times a week will have checkpoints like this:
For Example
To see how the checkpoint system works in practice, imagine a patient who is transported three times a week:
| Dates of Interaction | Checkpoint Used | Example Data |
|---|---|---|
| Monday, January 3 | Monday, January 3 | Primary insurance: Cigna |
| Wednesday, January 5 | ||
| Friday, January 7 |
Therefore, changes to checkpointed patient information -- for example, to the patient's phone number -- apply to all three calls during the relevant week.
The next week, a new checkpoint is taken, and automatically populated with data from the preceding checkpoint:
| Dates of Interaction | Checkpoint Used | Example Data |
|---|---|---|
| Monday, January 3 | Monday, January 3 | Primary insurance: Cigna |
| Wednesday, January 5 | ||
| Friday, January 7 | ||
| Monday, January 10 | Monday, January 10 | Primary insurance: Cigna |
| Wednesday, January 12 | ||
| Friday, January 14 |
Suppose the patient is serviced again the week after... When the new checkpoint is created, it is automatically populated from the preceding checkpoint, as we know. But now suppose that there is a change -- in this example, suppose the patient's primary insurance changes:
| Dates of Interaction | Checkpoint Used | Example Data |
|---|---|---|
| Monday, January 3 | Monday, January 3 | Primary insurance: Cigna |
| Wednesday, January 5 | ||
| Friday, January 7 | ||
| Monday, January 10 | Monday, January 10 | Primary insurance: Cigna |
| Wednesday, January 12 | ||
| Friday, January 14 | ||
| Monday, January 17 | Monday, January 17 | Primary insurance: Aetna |
| Wednesday, January 19 | ||
| Friday, January 21 |
That change applies to all records created that week, but it does not apply to earlier records, which in this example still carry the original primary insurance.
If the change was made to the latest checkpoint, it is then automatically carried forward into the future as new checkpoints are taken:
| Dates of Interaction | Checkpoint Used | Example Data |
|---|---|---|
| Monday, January 3 | Monday, January 3 | Primary insurance: Cigna |
| Wednesday, January 5 | ||
| Friday, January 7 | ||
| Monday, January 10 | Monday, January 10 | Primary insurance: Cigna |
| Wednesday, January 12 | ||
| Friday, January 14 | ||
| Monday, January 17 | Monday, January 17 | Primary insurance: Aetna |
| Wednesday, January 19 | ||
| Friday, January 21 | ||
| Monday, January 24 | Monday, January 24 | Primary insurance: Aetna |
| Wednesday, January 26 | ||
| Friday, January 28 |
Now suppose a biller is updating an older report, and he changes the primary insurance:
| Dates of Interaction | Checkpoint Used | Example Data |
|---|---|---|
| Monday, January 3 | Monday, January 3 | Primary insurance: Cigna |
| Wednesday, January 5 | ||
| Friday, January 7 | ||
| Monday, January 10 | Monday, January 10 | Primary insurance: UnitedHealthcare |
| Wednesday, January 12 | ||
| Friday, January 14 | ||
| Monday, January 17 | Monday, January 17 | Primary insurance: Aetna |
| Wednesday, January 19 | ||
| Friday, January 21 | ||
| Monday, January 24 | Monday, January 24 | Primary insurance: Aetna |
| Wednesday, January 26 | ||
| Friday, January 28 |
That change applies to all three calls for the week of January 10, but it is not carried forward to the records of later weeks. Certainly, crew members and billers can make any changes they wish to the later records; the point is that changes to earlier records are not automatically applied to later records once the later records have been checkpointed.
Modifying Several Checkpoints Simultaneously
Over time, every patient will develop a series of checkpoints, representing the patient's changing health and insurance information. If there is a mistake or omission in an early checkpoint, it will be carried onward to future checkpoints, until eventually caught and corrected.
In that situation, it would be annoying if every affected checkpoint needed to be changed manually. For example, suppose that the patient's insurance information contains a typo, and the typo was not caught for two months (when the insurance claims bounced). During that two-month period, the patient was seen at least once a week, and therefore accumulated a progression of snapshots, each containing the original typo.
This is easy to correct. In the Patient Edit page on the "Billing" tab you may elect to apply a change to a whole range of checkpoints:
This allows you to apply new or corrected insurance information across all affected checkpoints, all the way back to the first effective date of the policy.
Supplementary Checkpoints for Unusual Policy Start Dates
If a patient's insurance policy changes on an usual date -- say, on a Thursday, September 1st -- the change will land in the middle of the patient data checkpoint for Monday, August 28th. That could interfere with billing a trip on Tuesday, August 29th, against the prior insurance policy.
This doesn't happen very often, but when it does, you can solve it with a supplementary checkpoint.
AngelTrack's patient insurance controls offer the option to create a supplementary checkpoint for the linked dispatch, when applicable:
In this example, when you click "Save", AngelTrack will:
- Create a checkpoint for September 1st;
- Automatically populate the new checkpoint with data brought forward from the checkpoint for August 28th;
- Modify the new checkpoint to reflect the new insurance policy information; and then
- Utilize the new checkpoint for all dates of service going forward, i.e. the supplemental checkpoint will eclipse the earlier Monday checkpoint for all dates of service on or after September 1st.
On the following Monday, September 5th, a new regular checkpoint will be created, automatically populated with data brought forward from the supplemental checkpoint you created for Thursday.
"Why Isn't the PMHx Data Appearing in the Patient's Other Trips?"
There are two usual causes for this problem:
Duplicate patient records
If there is a duplicate patient record, then crews might be filling out one record but the data will not appear in the twin record.
It's necessary to regularly prune the patient records to merge the duplicates together. During a merge, AngelTrack gathers together the PMHx and billing data from both records in order to preserve as much of it as possible. To learn more about finding and merging duplicate patient records, refer to the Duplicate Patient Record Guide.
Slow report completion
PMHx data is checkpointed, and so gets carried forward into future checkpoints but not carried backward into older calls. This is true regardless of who enters the data -- be it a dispatcher, a biller, or a crew member.
Here is the gotcha: If crews are slow to finish their reports, then new checkpoints may be created before they’ve input the PMHx data into the prior checkpoints, and thus their input will not be carried forward.
For example, suppose a crew member runs a call on March 1st, but doesn’t input the PMHx data yet. A week later, on March 7th, the crew transports the very same patient, creating a new checkpoint to cover that week. The new checkpoint is created using the data from the prior week’s checkpoint – but the prior week’s checkpoint doesn’t contain any PMHx, so nothing gets carried forward. Now suppose that same day, the crew member finally finishes the report from March 1st, including the PMHx data. That new PMHx data will NOT appear in the PCR for March 7th, because it arrived too late to be included in the carry-forward.
AngelTrack does this to protect the crews from being wrongly second-guessed in hindsight. That is to say: AngelTrack does not inject newly discovered PMHx data into older reports because it might cause the attending's actions to then seem unjustified or negligent, when in reality the attending did the best he could with what he knew at the time.
Automatic Backwards Propagation of Missing Insurance Data
When insurance information is eventually typed in for a patient, that information is automatically applied to any older checkpoints that lacked it.
More specifically: When any crew member or biller updates a patient record and sets the "Primary Insurance Type" type to something other than "[Not recorded]", then the new insurance information will be saved to:
- the current checkpoint, as usual; and
- all older checkpoints in which the "Primary Insurance Type" field is still set to "[Not recorded]".
In this way, when a patient's insurance information is late arriving, the biller is saved the chore of copying the information over to the patient's older checkpoints. When the crew types the information in to the current checkpoint, the older ones are filled in too with no manual intervention.