Every action attributable to a person
In a blood centre, knowing who did what is not surveillance — it is the basis of traceability. RAKT records the actor on every record it stores.
Activity on the record
Staff detail screen
Permissions by role
simple-history on models
Accountability built into the record
Not a separate log to maintain, but a property of every entry.
Change history per record
What the value was, what it became, who changed it and when.
Role-based permissions
Staff see and change only what their role requires, per centre.
Shift and workload visibility
Registrations, collections, tests and issues attributable by person and period.
Tamper-evident trail
Records are amended with a trail rather than overwritten silently.
Exception visibility
Unusual actions — overrides, back-dated entries, discards — surface for review.
Evidence for assessment
When an assessor asks who validated that TTI result or approved that discard, the answer is on the record.
Attribution without a side spreadsheet
Open a staff member
Staff detail shows a date-filtered activity breakdown — registrations, processing, issues — from the same events the floor already writes.
Actors on the operational row
tested_by, verified_by, entered_by and friends live on TTI and related models. The question “who validated this?” is answered on the bag.
Organisation activity log
Settings exposes a filterable log of org-level actions. Permissions are edited per user, not by sharing one login across a shift.
Corrections notify management
Clerical-error paths can WhatsApp the people who need to know — the trail is the product, not a lecture about surveillance.
Attribution is a field, not a policy document
tested_by, verified_by, entered_by and the rest live on the operational models. Staff detail then rolls those events into a date-filtered activity view.
- Per-person activity breakdown on the staff detail screen
- Role permissions edited per user — not one shared login for the shift
- Organisation activity log filterable in Settings
- Clerical-error paths can notify management on WhatsApp when configured
Attribution is a safety property, not a management one
Staff tracking in most software is a productivity feature, and framing it that way in a blood centre gets it resisted for good reason. The purpose here is different. When a transfusion reaction is investigated, the question is not how productive anybody was; it is who recorded that grouping result, who validated that TTI screen, who authorised that discard, and what the value was before it was changed. Without attribution those questions have no answer, and an investigation becomes a conversation about what people remember. That is the actual argument, and it is worth making to staff in those terms, because a team that understands attribution as protection cooperates with it.
Two design decisions follow. The first is that history has to be append-only: a “last modified by” field is overwritten by the next edit and therefore records only the most recent change, which is precisely the wrong one when you are reconstructing a sequence. What you need is what the value was, what it became, who changed it and when, retained. The second is that accounts have to be individual, which is why RAKT does not charge per user. Per-seat pricing in a three-shift blood bank leads directly to rationed logins and shared credentials, and a shared credential means nothing is attributable to anybody, the pricing model quietly destroys the control.
The exception layer is what makes this usable rather than merely complete. A full audit trail nobody reads is an archive. What makes it operational is surfacing the small number of actions worth a second look: corrections recorded in the correction book, back-dated entries, discards, and entries that look unlike the normal pattern for that user or period. A quality manager reviews ten items a week instead of scrolling a log. That is also what an assessor is testing when they ask how you supervise: not whether the trail exists, but whether anyone looks at it.
Questions about staff activity tracking
Does RAKT record who changed a test result?
Yes: what the value was, what it became, who changed it and when, retained as an append-only history rather than a "last modified by" field that the next edit overwrites. That distinction matters when you are reconstructing a sequence rather than asking about the most recent change. Pick a result and ask us to show its history during the demo, and ask every other vendor the same.
Can we restrict what each staff member can see?
Yes, by role and by centre. A phlebotomist, a technician, a medical officer and a quality manager see different screens, and staff at one centre in a multi-centre network do not see another’s records. New accounts start at the minimum their role requires rather than inheriting a shared administrator login, which is the most common access-control failure we find at centres migrating in.
Is there a per-user charge for extra accounts?
No, and this is deliberate rather than generous. Charging per login makes a blood bank running three shifts ration accounts and share credentials, and a shared credential means no action is attributable to a person, which is exactly the evidence an NABH assessor asks to see. Pricing is per centre, so every member of staff who should have their own account can have one.
What evidence does this give us in an assessment?
When an assessor asks who validated a particular TTI result, who approved a specific discard, or how a changed value was authorised, the answer is on the record rather than in somebody’s recollection. The exception view also answers the harder question, which is how you supervise: it surfaces overrides, back-dated entries and unusual patterns for review, so there is a documented practice of looking rather than only a log that exists.
More of what RAKT does
See this running on your own floor
Tell us how your centre works today and we will show you the parts that would change.