Security & Compliance
Audit logging
ArkCloud keeps three separate logs: application events, a hash-chained security log for administrative and financial actions, and a log of access to protected health information. Each has a different coverage, and none of them records everything.
Written for: Security reviewers · Compliance officers · Administrators
The three logs
| Field or control | What it means |
|---|---|
| Application audit events | Sign-in success and failure, account lockout, and events written by most product features (account, payment, workflow and settings changes). Viewed at Audit. |
| Security audit log (hash-chained) | Administrative user actions - create, update, deactivate, reactivate, force logout, password reset, unlock, disable MFA - privilege-elevation requests and decisions; payment, pricing, statement, reconciliation, revenue-recognition and settlement events; manual charge overrides; consent changes and patient disputes; and records of AI-assisted decisions. Each entry carries a hash of the previous one. Viewed at Administration → Audit Logs. |
| PHI access log | Every opening of a patient record screen - who, when, which screen, which patient record and from which address. Administrators review it at PHI access log (footer of the ArkCloud launcher, /access-log), filtered by patient or by person. |
Can the logs be changed?
The application's database role cannot update or delete rows in any of the three logs. That is enforced by database privileges, not by application code. The one exception is a single column on the security log that marks an entry as archived; the entry's content cannot be changed.
| Field or control | What it means |
|---|---|
| Through the application | No. Entries can be added and read, not changed or removed. |
| By a database administrator | Yes. The database owner role is not restricted, and deleting an organisation removes its log rows with it. A user who has PHI access history cannot be deleted - the database refuses - so that history outlives the account (the application has no way to delete a user; accounts are deactivated). |
| The integrity check | Verify Integrity on the Audit Logs screen (administrators) walks the hash chain and reports a missing, re-ordered or edited entry. Edits are detected for entries written from 2 October 2026, whose hash can be recomputed from the stored fields; older entries are counted as legacy and checked for linkage (deletion and re-ordering) only. |
Coverage limits
- Every screen that opens a patient's record writes the PHI access log: patients, episodes, assessments, functional status, forms, message threads, referrals, accounts, claims, denials, appeals, estimates, financial-assistance applications, work queues, statements and portal messages. A new record screen cannot be added without it - an automated check fails the release.
- Reading an account's detail (demographics, contact details, guarantor and coverage), and each resource about a patient that the FHIR API returns, are also written to the PHI access log.
- Lists and search results that show patient names are not all logged row by row; work queues are. A CSV built in the browser (for example from a work queue) is not logged as an export.
- Searches, sign-outs and document downloads are not logged as such.
- If writing an application event fails outside a database transaction, the failure is logged to the server log and the user's action still completes.
- Nothing is alerted on automatically, and no one reviews the logs on a schedule yet.
- Logs are kept in the production database with no purge job. Archival to cold storage is not running, and no retention period has been set.
Reading and exporting
Launcher footer → PHI access log
Admin only. Shows who opened which patient record, newest first, for the last 7, 30 or 90 days or a year. Select a person or a patient record id to see only their entries. Patient records are shown by id, never by name.
Administration → Audit Logs
Filter by event, category, resource, actor and date; export to a file; run the integrity check. The application events log is at /dashboard/audit.