Reference table

The access log

A reference table of the events the access log holds, including who viewed a record and when, and the fields kept for each.

The access log is the record of who reached a patient's record, what they did, and when. This page is a reference to the events it holds and the fields it keeps for each one.

What the access log is

The access log is a first-class output of Cirith Manager. Every read that returns clinical data is recorded, and so are refusals, held decisions, emergency accesses and consent changes.

The entry is written with the decision

An access log entry is written inside the same transaction as the decision it describes. A committed access carries its log entry, so the log stays a truthful account of what the platform did.

Who sees the log

The two views of the log are one-directional. A patient holds the full cross-site view of every access to their own record. Each site holds the events that happened at that site.

The patient's view spans every site their record has reached. The site's view stays within its own walls, so one site reads its own events and the cross-site picture belongs to the patient.

The events the log holds

The log records access events across their outcomes. Reads that return data, reads that are refused, and changes to the relationships that grant access all leave an entry.

Event	When it is written
Record viewed	A read returned clinical data from the record.
Access refused	A read was refused as a genuine denial.
Detail requested	A read was held for a missing detail before proceeding.
Emergency access	A clinician invoked the emergency route with a stated reason.
Consent changed	A patient allow, deny, partition or restriction was written or withdrawn.
Access granted or ended	A role, care relationship or delegation was granted or ended.

The fields kept for each event

Every event carries a common set of fields. The fields name the person, the record, the action, the outcome, the time, the site, the purpose and the relationship behind the access.

person string Required	The member of staff or the patient who acted, named.
record string Required	The patient record the event concerns, by public identifier.
action string Required	The action taken, such as a record read or a consent change.
outcome string Required	Allowed, refused, held for a detail, or emergency.
at timestamp Required	When the event happened.
site string Required	The site the action happened at.
purpose string Required	The stated purpose of the access.
relationship string Required	The role and relationship that granted the access.
reason string	The stated reason, kept for an emergency access or a refusal.

A sample entry

The entry below records one emergency read, with the reason the clinician stated and the relationship that placed them at the record.

{
  "person": "dr.a.mehta",
  "record": "PEN-4417-2093-K",
  "action": "record.read",
  "outcome": "emergency",
  "at": "2026-08-20T02:14:07Z",
  "site": "central-hospital",
  "purpose": "urgent-care",
  "relationship": "consultant, care team, active admission",
  "reason": "Unresponsive patient in resuscitation, prior history needed"
}

Common questions

Does every record read appear in the log?

Every read that returns clinical data writes an entry in the same transaction as the decision. A committed read carries its log entry.

Does one site see another site's accesses?

Each site holds its own events. The full cross-site view of a record belongs to the patient, so a site reads only what happened within it.

What is kept for an emergency access?

The clinician and the stated reason are kept for the hospital's reviewer. The patient does not see the same entry. The individual clinician and the emergency justification are withheld from the patient's access log, which records the fact of the override, the hospital, the time, the purpose and the outcome.

See how a patient reads their own access history in who looked at my record.