Procedure
Answering who saw this record
Steps for producing an access history for one patient record, showing who viewed it, when, and the reason recorded for each access.
This procedure produces the access history for one patient record: the people who read or changed it, the moment each of them acted, and the reason recorded for that access. It is the answer a records officer gives when a patient, a reviewer or an accreditation team asks who has seen a record.
What an access history is
An access history is the list of audit entries for reads and changes to one patient's record. Each entry names who acted, when, what they touched, and the reason the access was allowed.
Before you start
Confirm the standing conditions below before you open the history. The platform holds the first three; you settle the review period yourself.
Produce the access history
The history is built from the audit trail, so it reads the same whether you open it from the record or from the access panel. Follow the steps in order.
- 1
Open the record and set the period
Open the patient record in Atlas and select its access history. Set the date range for the review, so the list covers the period in question and stays readable.
- 2
Read who acted
Each line names the person and the role they held at the time, at the site where the access happened. The name is the signed-in identity, so a shared workstation still resolves to one person.
- 3
Read when and what
Each line carries the moment of the access and the part of the record it touched, such as a document, a result or a clinical note. The line also shows whether the access was a read or a change.
- 4
Read the reason for each access
Each access carries the basis that allowed it. For ordinary care, that basis is a current care relationship established by the patient's admission and consent. Read the reason line alongside the person, so the history explains as well as lists.
- 5
Single out emergency access
Filter the list to emergency-access entries. Each one carries the clinician, the time, and the free-text reason they entered when they opened the access, so an urgent read stands on its own record.
- 6
Produce the history for the review
Export the list for the reviewer, or attach it to a patient's request to know who has seen their record. The exported history carries the same fields you read on screen.
What each access line holds
Every line in the history is one audit entry. The fields below are the ones a reviewer reads to settle the question.
| Field | What it holds |
|---|---|
| Who | The person who acted and the role they held at the time. |
| Site | The site where the access happened. |
| When | The moment of the access. |
| What | The part of the record touched, such as a document, a result or a note. |
| Action | Whether the access was a read or a change. |
| Reason | The basis for the access: a current care relationship, or an emergency access with a stated reason. |
Why the history is complete
The completeness of the history rests on one mechanism. Pensieve writes each audit entry inside the same transaction as the read or change it describes, so a committed access always carries its entry.
The entry travels with the access
Because the audit entry is written with the access itself, the history holds every access that took effect in the platform. A reviewer reads a full account rather than a sample. A downtime pack held at the hospital sits outside the platform, so reads of that file are accounted for by the hospital.
Common questions
Does a shared workstation blur who acted?
Each member of staff signs in as themselves on a shared workstation, so every line resolves to one named person, even across a busy shift.
How does an emergency access appear?
As an ordinary line with its own reason: the clinician, the time, and the free-text reason they entered when they opened the access.
Can a patient receive this history?
No. A records officer sees the individual clinician who acted, but a patient does not receive that same history. The patient's own access log names the hospital that read the record rather than the individual clinician, so clinician identity is withheld before anything reaches the patient.
Does the history cover the downtime pack?
No. The history covers reads that happen in the platform. Where the hospital holds a downtime pack at its site, reads of that file happen on the hospital's own storage and leave no line here, so the hospital accounts for them under its downtime procedure.
The access history draws on the audit trail and the access log, so its fields match theirs exactly. Read how the audit trail records each access at the audit trail, how the access log is structured at the access log, and how an urgent read is opened at emergency access.