The Inspector Asks for the Last Six Months
The request is always the same shape: show us what happened, over this period, and show us you have not edited it since. What a system can actually produce against that, what a checksum does and does not prove, and the row limits worth knowing before you hand something over.
An inspection notice, an insurer's review, a donor audit and a legal request all ask for slightly different things and all ask in the same shape: evidence of what happened over a period, and some reason to believe it has not been tidied up since the request arrived.
The response most facilities can assemble is a set of exports produced last week by somebody using the filters they thought were relevant. It is usually accurate. It is also unverifiable, incomplete in ways nobody can characterise, and shaped by whoever ran it — which is precisely the combination that makes an examiner ask a second question.
This post is about what a system can honestly produce against that request, and — more usefully — about the three or four properties of such a bundle that determine whether it is worth anything.
What is actually being asked
It is worth separating the request into its parts, because a bundle can satisfy one and not the others, and knowing which is which saves an unpleasant conversation.
- Completeness. Is this everything for the period, or a selection? A selection is not evidence of anything except what somebody chose to show.
- Attribution. Does each record say who did the thing and when? An event with no actor is an assertion.
- Integrity. Is there a reason to believe this file is the one that was produced, unmodified?
- Scope. Does it cover what was asked about, and does the recipient understand what it does not cover?
- Reproducibility. If somebody runs it again, do they get the same thing?
A folder of ad-hoc exports fails the first, third and fifth. That is not a criticism of the person who made them — those properties come from how a bundle is produced, not from how carefully it is produced.
A selection is not evidence of anything except what somebody chose to show. That is the whole difference between an export and a pack.
What the evidence pack contains
Five sections, which you choose from when you request the pack. Each is a distinct kind of record and each answers a different question, so it is worth being deliberate about which you include rather than taking all five out of caution.
| Section | What it evidences |
|---|---|
| Audit logs | What was changed in the system, by whom, and when |
| Approvals | What was authorised, by whom, and against what |
| Trash lifecycle ledger | What was deleted, by whom, and what became of it afterwards |
| Access history | Who reached which records |
| Document activity | What was uploaded, and who opened it |
The third one is the section people do not expect and the one an examiner is most likely to care about, because "what was deleted" is the question that ad-hoc exports structurally cannot answer. An export shows what is there. A deletion ledger shows what is not, and why it stopped being there.
How it is produced, and why that matters
The mechanics sound like implementation detail and they are actually most of the value, because each choice maps to one of the properties above.
-
Requested, then built in the background
A pack is requested with its sections and filters, and the archive is assembled on a queue rather than in the browser. That means a genuinely large period does not time out into a partial file that looks complete.
-
One file per section, in a plain format
Each section becomes a CSV inside a single archive. Plain, openable by the recipient with whatever they have, and not dependent on a viewer you would have to supply.
-
A manifest travels with it
The archive carries a manifest recording the sections included and how many rows are in each. The recipient does not have to take your word for the shape of what they were given.
-
A checksum is computed and stored
A SHA-256 hash of the finished archive is recorded alongside its size and the time it was generated. If the file is altered afterwards, the hash no longer matches the record.
-
The build does not depend on who is logged in
Everything is derived from the stored request rather than from the session that made it, so the same request produces the same pack regardless of who triggers the build.
What a checksum proves, and what it does not
It proves that the archive you are holding is byte-for-byte the archive that was generated at that timestamp. That is genuinely useful and it is a narrow claim. It does not prove the archive is complete, it does not prove the underlying records were never altered before generation, and it is not a legal attestation. Anyone presenting a hash as proof of evidential integrity is claiming considerably more than a hash can support.
The row limits, and why you should know them first
Each section is capped. Audit logs and the deletion ledger take up to five thousand rows, approvals and access history up to three thousand, and some sub-sections a thousand.
For most facilities and most periods those caps are never reached. For a busy organization over six months, the audit log cap in particular can be, and the behaviour when it is deserves stating plainly: the manifest records how many rows are in the file, not how many existed. Nothing marks a section as truncated.
The practical response is straightforward and worth building into how you use it. Request packs over shorter periods — monthly or quarterly rather than annually — so each section stays well inside its cap, and hand over a set of packs rather than one. That is also a better answer evidentially, because a monthly rhythm produced before anybody asked is far more persuasive than a single annual bundle produced the week after a notice arrived.
What AWRA OpsHub does today
- Five sections — audit logs, approvals, deletion lifecycle, access history and document activity — chosen per request.
- Assembled on a queue, so a large period does not become a partial file that looks whole.
- One CSV per section in a single archive, plus a manifest recording the sections and their row counts.
- A SHA-256 checksum, size and generation time stored against the pack, so a later copy can be compared with what was produced.
- Built from the stored request rather than the session, so the same request produces the same pack.
What it does not do
- Sections are capped and truncation is not flagged. Up to five thousand rows for audit logs and the deletion ledger, three thousand for approvals and access history, and the manifest reports what is in the file rather than what existed. Request shorter periods so the caps are never approached.
- No clinical or patient records. This is system activity — who changed what, who approved what, who opened what. A clinical evidence request is answered from your clinical system.
- No signing or notarisation. The checksum is a hash stored alongside the pack, not a cryptographic signature by an independent party, and it should never be presented as one.
- No scheduled generation. Packs are produced on request. A monthly rhythm is a calendar entry and a named person, not something the system does for you.
Not ours, by choice
- We will not tell you a pack satisfies a particular standard. What an inspector, insurer or regulator will accept is their judgement, and a vendor asserting compliance on a marketing page is offering you an assurance they are in no position to give.
- We will not exclude the deletion ledger from an evidence pack, or offer a mode that quietly omits it. A bundle that shows only what survived is not evidence, and the section that records what was removed is the one that makes the rest credible.
Scheduled monthly generation, an explicit truncation flag in the manifest, and higher or configurable caps are all scope rather than ceilings — the queue, the manifest and the checksum all exist and work, so each is a written specification and a price.
The most useful thing you can do with this feature costs nothing and has to be decided in advance: generate packs on a monthly rhythm, before anyone asks. Evidence produced routinely carries a weight that evidence produced in response never quite does, and it also means you find out what is in it while there is time to do something about it.
What to do before a request arrives
Every part of this works better if it was set up months earlier, and the setup is mostly not technical.
Worth doing now rather than then
- Generate one pack today over last month, and open it. Whatever surprises you is the thing to fix while it is cheap.
- Check that your users are actually distinct people. An audit log full of a shared login evidences nothing, and no pack can repair that after the fact.
- Decide who is permitted to request a pack, and make sure it is more than one person. A capability held by somebody on leave is not a capability.
- Put monthly generation on a calendar with a name against it, and store the packs somewhere separate from the system that produced them.
- Record the checksum somewhere outside the archive — an email to yourself on the day is enough, and it is what makes the hash worth anything later.
- Agree internally what the pack does not cover, so nobody promises an inspector a clinical trail that lives in a different system.
The second item is the one that most often turns out to matter. Attribution is the property an examiner probes first, and a shared account converts every record in the pack from evidence of who did something into evidence that somebody did — which is a very different document.
The custody-record equivalent of this argument is in who signed for the defibrillator, the document-register side in the licence that expired in a drawer, and the batch evidence trail in the recall notice arrives on a Friday.
The deletion question
Worth returning to, because it is the section that distinguishes a real evidence bundle from a thorough export, and it is also the one that makes people uneasy.
The discomfort is understandable — a ledger of everything anybody deleted looks like an invitation to be questioned about ordinary housekeeping. In practice it works the other way round. An organization that can show what was removed, by whom and when, is demonstrating a system where removal is visible, and that is a far stronger position than one that can only show what remains.
The alternative is worse in a specific way: without such a ledger, the honest answer to "was anything deleted during this period" is "we cannot tell", and that answer invites exactly the scrutiny the bundle was meant to close.
Our take
Generate a pack this week over last month, and open it — everything you learn from that is cheap now and expensive later. Then set a monthly rhythm with a name against it, record each checksum somewhere outside the archive, and keep the periods short enough that the row caps are never approached, because truncation is not flagged. And be precise about what a checksum proves: that this archive is the one that was generated, unmodified. Not that it is complete, not that the records behind it were never touched, and not that any standard has been met. A narrow claim stated accurately is worth considerably more than a broad one that will not survive a follow-up question.
See what an evidence pack contains
Five sections including the deletion ledger, one CSV each in a single archive, a manifest with row counts, and a stored SHA-256 checksum with the generation time.
Explore compliance toolingFrequently asked questions
What is in an evidence pack?
Up to five sections, chosen when you request it: audit logs of what was changed and by whom, approvals of what was authorised, a trash lifecycle ledger of what was deleted and what became of it, access history of who reached which records, and document activity covering uploads and opens. Each becomes a CSV inside a single archive, alongside a manifest listing the sections and the number of rows in each. It is system activity rather than clinical records — a patient-data request is answered from your clinical system.
What does the checksum actually prove?
That the archive you are holding is byte-for-byte the one generated at that timestamp. It is a narrow and genuinely useful claim, and it is worth being precise about its edges: it does not prove the archive is complete, it does not prove the underlying records were never altered before it was generated, and it is not a signature by an independent party. Presenting a hash as proof of evidential integrity claims a great deal more than a hash can support, and it will not survive a follow-up question from anybody who knows what one is.
Are there limits on how much a pack contains?
Yes, and this is the thing to know before you hand one over. Audit logs and the deletion ledger take up to five thousand rows, approvals and access history up to three thousand, and some sub-sections a thousand. The manifest records how many rows are in the file rather than how many existed, so nothing marks a section as truncated. The practical answer is to request monthly or quarterly packs rather than annual ones — which is also better evidentially, since a routine rhythm is more persuasive than a single bundle produced after a notice arrived.
Why does the pack include what we deleted?
Because it is the question an ordinary export structurally cannot answer, and it is the one an examiner is most likely to ask. An export shows what is there; a deletion ledger shows what is not, and why it stopped being there. It feels exposing and it works the other way round — an organization that can show what was removed, by whom and when, is demonstrating that removal is visible in its system. The alternative is answering "we cannot tell", which invites exactly the scrutiny the bundle was meant to close.
Can packs be generated automatically each month?
Not today — they are produced on request, and a monthly rhythm is a calendar entry with a named person against it rather than something the system does for you. It is worth setting up anyway, and worth storing the packs somewhere separate from the system that produced them, with each checksum recorded outside the archive. An email to yourself on the day is enough, and it is what makes the hash worth anything six months later.
What is the most common problem people find in their first pack?
Shared logins. Attribution is the property an examiner probes first, and an audit log full of a single shared account converts every record from evidence of who did something into evidence that somebody did — a materially weaker document, and one that no pack can repair after the fact. Generate a pack over last month today, open it, and look at the actor column before you look at anything else.
