In development
Audit Replay Timeline is being built. It is not part of any plan today, and nothing on this page describes a capability you can use yet. The rest of the page describes the intended product. It is intended for the Pro plan.
See what ships todayIntelligence · Audit Replay Timeline
Reconstruction, built from records the platform already keeps.
In development. The evidence it would read — who opened what, when, and what state changed around it — is being recorded today; assembling it into a sequence on demand is the part we are building.
HIPAA mapping
Where this fits in the Security Rule.
2 provisions this capability contributes to, each with the specific Audit Replay Timeline behavior behind it. The obligation stays with your practice — the mapping shows which part of the work the platform carries.
§164.312(b)Audit controls
Requires mechanisms that record and examine activity in systems containing ePHI. Recording is live today in the ePHI Audit. The examining half — assembling what was recorded into a sequence around one incident — is what this page describes and what is not yet built.
§164.316(b)(2)Time limit
Six-year retention of audit data. The full retention window is replayable; not just the most recent activity.
What it does
From investigation hours to investigation minutes.
When something goes wrong — an incident, a complaint, an audit inquiry, a workforce dispute — the question is always the same: what happened, in what order, by whom. Most practices answer the question by piecing together fragments. Calendar entries, email threads, the EHR's audit log, the front-desk's paper signals. The reconstruction takes hours; the result is rarely complete; gaps in the timeline become defensibility gaps.
The Audit Replay Timeline reconstructs the event from the platform's evidence directly. Every recorded action — every login, access, edit, message, form submission, BAA state change, training completion, role change, alert — feeds the timeline with timestamp and attribution. Pick a window, pick a focus (workforce member, patient record, vendor, incident); the timeline assembles. The reconstruction is minutes, not hours, and the evidence chain is complete by architecture.
The replay isn't just events; it's reconstructed state. At any point in the timeline, the platform shows what was true: which roles existed, which BAAs were active, which policies were in force, which training had been completed. State at time-T is recoverable, not just events around time-T.
How it works
7 mechanisms we intend to build.
It would read what is already being kept.
The reason this is worth building is that the records exist. Access is already attributed to named workforce members with timestamps, events already carry occurrence and action times, and policy changes already produce versioned edits. What does not exist is the ability to ask for all of it around one incident and get a sequence back.
Assembly rather than reconstruction.
The intended job is to answer “what happened around this” without a person opening four screens and building a chronology by hand. What it can be focused on — a person, a patient, a vendor, a date range — is not settled, and this page is not going to pretend otherwise.
The question is usually about a date.
What was true on the fifteenth of March is the shape an investigation actually takes, and it is harder to answer than a list of events. Whether the platform can answer it well enough to be worth shipping is an open engineering question, not a feature we are announcing.
One incident, several places.
An incident rarely sits in one module — there is access on one side, an exchange on another, a state change somewhere else. Bringing those together around a single subject is the reason to build this rather than improve any one log.
Concept, not specification.
How a reconstructed sequence would be filtered, exported or presented is undecided. We are describing a direction here, and listing controls we have not built would make this page exactly the kind of thing this audit exists to remove.
What exists today instead.
The ePHI Audit is live: choose a workforce member and read what they accessed, with the patient, the action and the time on each row. That is the record a replay would draw on, and it is available in Basic now.
Chain-of-custody preservation.
Audit events are retained and stored under access controls that prevent modification through the application's own workflows. The intent is that any assembly would read those source records directly rather than a derived copy, so what it showed would be faithful to the underlying evidence. Practices defending against allegations of evidence manipulation benefit from this — the chain of custody is architected, documented, and reviewable.
Who this is for
Built for the practices that need it most.
Practices who have had to reconstruct one.
If you have ever assembled a chronology by hand from three screens and somebody's memory, you already know why this is worth building. Today the ePHI Audit gives you the per-person half of it, which is the half most investigations start from.
Practices who expect to be asked.
The questions are about dates and people. What was true then, who touched what. Records made at the time are the only thing that answers them, and those are being kept now whether or not this ships.
Practices watching this space.
If reconstruction is what you are shopping for, the useful information is that it is in development and not available in any plan or in the trial. The ePHI Audit is live and is the nearest thing today.
What you get
3 outcomes it is meant to produce.
In development.
Not in Basic, not in Pro, not in the trial.
The evidence is being kept now.
Which is the part that cannot be created later.
Live today: the ePHI Audit.
Per-person access history with patient, action and time.
Can I use this today?
What exists today instead?
How settled is the design?
Why publish a page for something unbuilt?
Continue exploring
Related features in the platform.
Defense
ePHI Audit
The question after an incident is never abstract. It is whether one named person opened one named record on one particular afternoon, and whether you can show it.
Learn moreSystem
Autonomous Compliance Engine
Your practice state produces the next thing worth doing — from the assessment, but also from a lapsing BAA, a policy change, a new workforce member. Work closes when its conditions are met, and closing it changes the state.
Learn moreSystem layer
Patient Protect Score
Any past score state can be replayed from the underlying events; full reconstruction of “what changed” between two past dates.
Learn moreIn development. The records it would read are not.
An audit trail cannot be created after you need it. That part is live in Basic today, and it is the precondition for everything this page describes.