“Real time” is the least reliable phrase in pharmacy software sales. It gets used for a nightly export, a fifteen minute poll, a screen scrape and an actual event stream, with no distinction drawn. If you are comparing vendors, the difference determines whether the numbers you are looking at are worth acting on before the wholesaler order goes out.
Here is exactly how the PioneerRx integration works, what the words mean in this context, and where it breaks.
The mechanism
PioneerRx documents an Rx Event API that transmits details about a prescription and related data based on specific events within the system, in real time or near real time. Its published documentation describes transmission over HTTPS web services using the standard HTTP POST method, with data sent as JSON or XML. Attergo is a consumer of that feed and nothing more.
Three properties matter more than anything else in the datasheet.
It is push based, not polled. Attergo is not logging into your system every ten minutes asking what changed. The pharmacy system POSTs an event when the underlying activity happens. A polled integration has a latency floor equal to its polling interval, and it puts load on your system whether or not anything happened.
It is one directional. Events leave PioneerRx and arrive at Attergo. Nothing travels the other way. Attergo has no write path into your pharmacy system, so no configuration mistake on our side can alter a prescription record on yours.
The events are selectable. PioneerRx describes the events as customizable, with one or more chosen to transmit to a third party. That is worth knowing during procurement, because the scope of what leaves your system is a decision, not a fixed package. It is reasonable to ask any vendor which events they require rather than which they would like.
One scheduling note that catches buyers out. Turning on a third party feed in PioneerRx generally runs through their data programs process, which involves the vendor being approved rather than you simply flipping a setting. That is their process and not ours, and it is the main reason we will not promise you a same day connection.
Credentials are per store, and that is not a formality
Because the pharmacy system POSTs outbound to a destination, the credential works the way round that people often assume backwards. Attergo issues a Basic Auth credential pair for each store and that credential is configured as the authentication for that store’s event delivery. Every POST that arrives is therefore authenticated as one specific location, or it is rejected.
The alternative, one credential for a chain, is easier to set up and considerably worse to live with:
- Revocation becomes all or nothing. Rotating a compromised credential takes down every store at once.
- Attribution disappears. When something arrives malformed, you cannot tell which location produced it.
- Offboarding a location means touching the credential every other location depends on.
Per store credentials mean the blast radius of a leaked secret is one store, and disconnecting a location is a local action.
Basic Auth over TLS is a plain mechanism and deserves plain treatment. It is a bearer secret: whoever holds it can send events that will be accepted as coming from that store. It should be handled like a key to the building, rotated when staff with access to it leave, and never left sitting in a shared spreadsheet or a chat thread. How a vendor transmits and stores that secret at setup is a fair thing to ask about, and evasiveness on the question is a legitimate reason to walk away.
What real time actually means here
Real time in this integration means an event is typically visible in Attergo within seconds to a small number of minutes of the underlying activity, not that it is instantaneous and not that it is guaranteed.
The path has several links, and each adds delay:
- Activity occurs in the pharmacy system and an event is emitted.
- The event traverses the network from the store.
- Attergo receives, authenticates and archives it.
- Attergo parses it and updates the derived numbers.
Step two is where precision is required. Your store’s internet connection is part of the pipeline. If the line drops during a busy afternoon, events queue and arrive as a burst when it recovers. Nothing is lost, and the counter is unaffected, but the dashboard is behind reality until the queue drains.
We are not going to publish a latency guarantee that depends on your ISP. Any vendor who offers you a hard number for end to end freshness across an infrastructure they do not control is quoting a best case as a promise.
Archive first, then parse
This is the design decision worth understanding, because it determines what happens when something goes wrong.
Every event is written to an immutable archive before anything tries to interpret it. The raw payload is stored exactly as received and retained for ten years. Only then does the pipeline attempt to parse it into structured data and update margin.
The consequence is that a parsing bug cannot lose your data. It can only delay a derived number. When the bug is fixed, the events are still there, in their original form, and the derived numbers can be rebuilt from them.
Contrast a pipeline that parses first and stores only the result. If the parser mishandled a field in March, the original is gone, and you have an archaeology problem rather than a recovery problem.
Idempotency, retries and the dead letter queue
Distributed systems deliver messages more than once. Anyone claiming otherwise has not run one.
Events carry identifiers, and processing is keyed on them. Receiving the same event twice produces the same state as receiving it once. Without this, a retry after a timeout would double count a fill, and the margin number would be wrong in a way nobody notices until it is quoted in a negotiation.
Failures are handled in three tiers:
| Failure | Handling |
|---|---|
| Transient (timeout, brief unavailability) | Retry with backoff, the event is already archived |
| Malformed or unparseable | Routed to a dead letter queue, retained, surfaced for investigation |
| Authentication failure | Rejected, not archived as a valid store event, logged as a security relevant occurrence |
A dead letter queue is unglamorous and essential. An event we cannot interpret is set aside for a human rather than silently dropped. The alternative, a pipeline with no place to put confusing input, discards it and reports success. Your dashboard then looks healthy while quietly missing fills.
Ask any vendor what happens to an event their parser cannot read. “That does not happen” is the wrong answer.
What this one connection is meant to carry
Attergo is eight products: Margin, Billing, Audit, Authorizations, Inventory, Compliance, Intelligence and Integrations. The ingestion spine exists precisely so that all of them run off the same event stream and the same archive. Activating Billing or Inventory later is a decision made in the platform, never a second integration project in your store.
That is the architecture, and it is the reason a PioneerRx connection is worth more than a margin report: the same credential that prices your fills today carries your audit evidence, your billing encounters and your purchasing signals, on infrastructure that was engineered for all of it from the first migration.
PioneerRx is the reference integration. Other pharmacy management systems onboard through the integration program, scoped against what each vendor exposes, with the timeline stated in the first conversation.
Questions worth asking before you sign
- Is the integration push based or polled, and if polled, at what interval?
- Are credentials issued per store or per organization?
- Is the raw payload stored before it is parsed, and for how long?
- What happens to an event your system cannot parse?
- How do you prevent duplicate delivery from double counting?
- Does anything your system does write back into my pharmacy system?
- If my internet drops for four hours, what do I lose?
The last one has a specific correct answer for this architecture: nothing is lost, the dashboard lags until the queue drains, and the counter never notices.
The trade off, stated plainly
An event driven, read only, archive first integration gives you freshness measured in seconds to minutes, an auditable original record for a decade, and zero risk to your dispensing system.
What it does not give you is retroactive history at connection time, a guaranteed latency figure, or any ability to act inside your pharmacy system. Those are consequences of the same choices that make it safe. If they are dealbreakers, better to find that out now.