Most software evaluations in an independent pharmacy get stuck on the same unspoken question: how much of my staff’s day does this cost me. Not the license fee. The interruptions, the retraining, the third system somebody has to remember to update, the new reason a fill takes ninety seconds longer on a Monday afternoon.
This piece answers that directly, including the parts that are not flattering.
The short version
On day one, your technicians see nothing. Your pharmacist in charge sees nothing. No new screen appears inside the fill workflow, no field becomes required, no popup interrupts a verification.
The person whose day changes is whoever owns the numbers, usually the owner or a manager. They get a login, a two factor enrollment, and a per fill margin view.
That asymmetry is deliberate, and it is the most important design decision in the product.
Why nothing changes at the counter
Attergo reads. It does not write.
The integration consumes prescription events from your pharmacy management system (PioneerRx today) through its Rx Event API. Events flow one direction: out of the pharmacy system, into Attergo. There is no return path. Attergo cannot change a price in your system, cannot hold a fill, cannot annotate a patient record, cannot queue a task for a technician.
That is a constraint in the architecture, not a soft policy. A one way read means:
- Nothing Attergo does can slow a fill, because Attergo is not in the fill path.
- An Attergo outage is invisible at the counter. Events queue and arrive later.
- A bug in our margin logic cannot corrupt your dispensing record. The worst case is a wrong number on a dashboard.
The cost of that constraint is equally real. Attergo can tell you a fill lost money. It cannot reprice it, flag it in the queue, or stop the next one. If you want a product that intervenes in the workflow, this is the wrong architecture, and it is better to know now than in month three.
One connection, eight products
Attergo is a platform of eight products, not a margin report. A single per store connection feeds all of them, so activating a product later does not mean another integration project, another credential, or another vendor in your store.
| Product | What it does on that connection |
|---|---|
| Attergo Margin | Per fill margin against acquisition cost, in real time |
| Attergo Billing | Clinical encounters to medical claims to remittance |
| Attergo Audit | Evidence assembly and PBM audit response |
| Attergo Authorizations | Prior authorization detection, submission and renewal |
| Attergo Inventory | Purchasing and stock against real demand |
| Attergo Compliance | Licenses, credentials, attestations and controls |
| Attergo Intelligence | Cross store dashboards and trend analysis |
| Attergo Integrations | The event spine every other product runs on |
The practical consequence for staff is that every product arrives on the connection you already made: no second onboarding, no second credential, no new step at the counter. That is the reason the platform is built on one ingestion spine rather than as eight separate tools.
What onboarding actually asks of you
The setup work is short, and almost none of it lands on counter staff.
| Step | Who does it | What it involves |
|---|---|---|
| Approve the feed | Owner, with PioneerRx | Enabling a third party feed generally runs through PioneerRx’s data programs process |
| Configure delivery | Owner or IT contact | Point the store’s Rx Event API at Attergo, using the per store credential we issue |
| Enroll two factor | Every Attergo user | TOTP app enrollment, mandatory, no opt out |
| Provide acquisition cost | Owner or buyer | A cost file, or accept NADAC as the starting basis |
Credentials are per store, not per chain and not per user. Because the pharmacy system posts events outbound, that credential is what each delivery authenticates with, so every arriving event is attributable to one location. Turning off one store does not disturb the others.
The variable we cannot promise is the approval step, which runs on PioneerRx’s data programs timeline rather than ours. We would rather not quote a setup time we do not control.
The first thing that surprises people
Event feeds are forward looking. When you connect a store, Attergo starts receiving events from that moment onward. Connecting on a Tuesday does not retroactively deliver last quarter’s fills.
So the first week is quiet by design. You see the fills that happened since you connected, and the picture gets more useful as history accumulates. Anyone describing a real time event integration that produces a full year of trend analysis on the first afternoon is describing a different mechanism, a database extract, with different privacy and access implications. If you need historical analysis on day one, raise it separately.
What the owner sees
Per fill margin, calculated against acquisition cost, with the cost basis shown next to every number.
That last clause is worth pausing on. Every margin figure carries a label saying where its cost came from: your invoice, NADAC, or a manual override. A margin computed from a real wholesaler invoice and one computed from a national average are not the same quality of number, and a dashboard presenting them identically is quietly misleading you.
This makes some screens busier. A number you cannot audit is worse than a number with a caveat attached, particularly when you are about to take it into a conversation with a wholesaler or a PBM.
What we deliberately do not do
Some are architectural, some are ordinary sequencing. Both are marked.
We do not write back to your pharmacy system. Architectural. Not planned to change.
We do not touch patients or clinical decisions. No portal, no messaging, no patient facing surface, and no clinical advice. Attergo has opinions about money, not therapy.
We do not send protected health information outside the application. None appears in application logs or in any email we send. If a future alert says margin fell on a drug class, it will say that and nothing more. This limits how useful notifications can be, and we accepted the limit.
We do not page your staff. Exceptions land in a work queue with an owner, and digests arrive on your cadence. A system that interrupts the counter every time a claim adjudicates badly would train everyone to ignore it, which is worse than no alerting at all.
The security posture, briefly
Three things are in place today, and they shape day one whether or not anyone notices.
- Tenant isolation enforced in the database itself, not only in application code. A query that forgets a filter returns nothing rather than another pharmacy’s rows.
- Mandatory two factor, via TOTP.
- An append only log of every access to protected health information. Nobody, including us, edits it. If you later need to answer who looked at what, the record exists.
Those three controls are the foundation the rest of the platform stands on, which is why they live in the database rather than in application code.
What to ask any vendor in this category
Two questions separate integrations that are safe to run in a live pharmacy from ones that are not. Does your integration write back into my pharmacy system, and under what conditions. If your service fails at 2pm on a Friday, what happens at my counter. We have a longer list in what to ask a pharmacy revenue analytics vendor before you sign.
The summary
Day one is uneventful, and that is the point. The connection is read only, per store, forward looking, and invisible to counter staff. The value shows up for whoever is responsible for margin, and it compounds as history accumulates.
If you need software that intervenes in the dispensing workflow or reconstructs last year on the first afternoon, this is a different architecture, deliberately. If you want an accurate, auditable view of what each fill actually earned, without adding a keystroke to a technician’s day, that is exactly what it delivers.