A PBM audit letter asks for a specific set of claims, as they stood on the dates they were adjudicated, with the supporting detail attached. Your current data is not what it wants.
That distinction sounds academic until you try to answer one. Most systems are built to tell you what is true now. An audit asks what was true then, and those are different questions with different storage requirements.
The difference between state and history
A conventional system stores current state. A record has fields, the fields have values, and when something changes, the values are overwritten. It is efficient, it is how most software is built, and it is lossy by design.
An event sourced system stores what happened. Each event is recorded as it arrived and never modified. Current state is derived by replaying those events. The events are the record of truth, and the tidy summary table is a convenience built on top of them.
The difference shows up on exactly the day you least want a surprise.
| Question | State based system | Event sourced system |
|---|---|---|
| What is the price on this NDC? | Immediate | Immediate |
| What was it on March 14? | Only if someone thought to keep a version | Replay to that date |
| Why did this figure change? | Usually unanswerable | Visible in the event sequence |
| Has the underlying record been altered? | Hard to prove either way | The archive is append only |
What the archive actually is
Every event Attergo receives from the PioneerRx Rx Event API is written to an immutable archive before anything attempts to interpret it. The raw payload is stored as received. Retention is ten years.
Three properties do the work.
Immutable. Events are appended, never edited or deleted. No administrative screen quietly corrects history, and no path exists by which our support staff can revise what a store sent.
Raw. The original payload is kept, not our interpretation of it. If our parser misread a field for a period, the source is still there and the derived numbers can be rebuilt.
Long retained. Ten years, because lookback periods and disputes do not respect a two year data policy.
What this means when the letter arrives
An audit typically opens with a notice letter naming a lookback window, commonly in the range of twelve to twenty four months, and identifying claims by date range, by drug, by prescriber, or by some combination. Some states constrain that reach: Connecticut, for example, limits the scope of a pharmacy audit to the twenty four month period after the claim was submitted, unless a longer period is required by law. Your own state and your PBM provider manual govern the specifics, and the two do not always agree.
Answering means assembling, for each claim, what was submitted, what came back, and what supports it. The supporting material PBM provider manuals generally call for is broader than people expect: prescription hardcopies, signature logs, prior authorizations, prescriber records, and purchase invoices showing you actually acquired the product you dispensed. That last item is why acquisition cost data and audit defense are the same problem wearing different clothes.
With an immutable archive, that assembly is a query over records that existed before anyone knew this audit was coming. Evidentially, that is the whole game. Data compiled after a request, from a system where anything could have been amended in the interim, invites the obvious question about what changed. Data drawn from an append only archive does not.
It also handles the awkward middle case. Sometimes an audit turns up a genuine error on your side. When history is intact, you can see precisely when the practice started, when it stopped, and how many fills were affected. Scoping a problem yourself beats the auditor scoping it for you.
Why the archive is the product
An audit tool bought the week the letter arrives cannot manufacture the history it needed to have been collecting. An archive only defends the period it has been running.
So Attergo’s evidence layer starts accumulating the moment you connect: the immutable ten year raw archive, per store credentials, database enforced tenant isolation, mandatory TOTP two factor, and an append only log of every access to protected health information, all underneath Attergo Margin’s per fill economics and Attergo Audit’s response assembly.
Every product on the platform reads that same archive. The response packet is only as defensible as the record it is assembled from, so the record was engineered first and hardest.
Why not just keep good records yourself
Many pharmacies do, and it is a fair question.
The problem is coverage and cost, not diligence. Manual documentation captures what somebody thought to capture. It is thin on the specific fill that later becomes contentious, because nothing marked that one as interesting at the time. It is also expensive in exactly the hours you have least of.
An event archive is indiscriminate. It keeps everything, because it does not know which fill will matter, and storage is cheaper than reconstruction.
Neither approach is free. The archive gives you completeness and costs you nothing in labor. Manual records give you context a system cannot infer, such as the phone call with the prescriber. The two are complementary, and the archive is the part software should be doing.
The other side of retention
Ten years of prescription events is a serious quantity of protected health information, and it has to be controlled.
Three controls are live today:
- Tenant isolation enforced in the database, so a query that omits a filter returns nothing rather than another pharmacy’s rows.
- Mandatory two factor via TOTP, with no option to disable it.
- An append only log of every access to protected health information, which we cannot edit either.
Protected health information does not appear in application logs or in any email the system sends. That constrains what notifications can usefully say, and we took the constraint over the exposure.
If you would rather not have a vendor holding a decade of your dispensing history, that is a coherent position. It also means that when an audit reaches back further than your own records, the reconstruction will be manual.
Questions to put to any vendor
- Do you store the raw payload you received, or only your interpretation of it?
- Can any employee of yours, at any level, edit or delete a stored event?
- How long is data retained, and what happens at the end of that period?
- If your parser had a bug last year, can the derived numbers be rebuilt?
- Can I export the underlying records, not just a report?
- Can you demonstrate each of these controls on a live system, today?
The last question gets skipped most often, and it separates a working system from a diagram. Ask it of every vendor, ours included, and insist on the demonstration.
In summary
An audit is a question about the past, and you cannot answer it from a system that keeps only the present. Attergo’s archive is immutable, raw, per store and retained for ten years, and it starts collecting the day you connect.
Hold every vendor you evaluate to the same standard: not whether they show you a response packet, but whether the record behind it existed, immutably, before anyone knew the question was coming. Book a demo and start the clock on yours.