“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 decides whether the numbers in front of you are worth acting on before the wholesaler order goes out.
Here is how the PioneerRx integration works, 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 consumes that feed and does nothing else to your system.
Three properties matter more than anything 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. Worth knowing during procurement, because the scope of what leaves your system is a decision rather than a fixed package. Ask any vendor which events they require, not 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 flipping a setting. That timeline is theirs, and it is why connection dates get quoted as a range.
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 authenticates that store’s event delivery. Every POST that arrives is authenticated as one specific location, or it is rejected.
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. Handle it like a key to the building. Rotate it when staff with access leave, and keep it out of shared spreadsheets and chat threads. How a vendor transmits and stores that secret at setup is a fair question, and evasiveness on it is a legitimate reason to walk away.
What real time actually means here
An event is typically visible in Attergo within seconds to a small number of minutes of the underlying activity. Not instantaneous, and not 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 will not publish a latency guarantee that depends on your ISP. Any vendor offering you a hard number for end to end freshness across infrastructure they do not control is quoting a best case as a promise.
Archive first, then parse
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 parse it into structured data and update margin.
A parsing bug therefore 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 rebuild 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 instead of 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 that, 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. 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 carries
Attergo is eight products: Margin, Billing, Audit, Authorizations, Inventory, Compliance, Intelligence and Integrations. The ingestion spine exists so 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 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.
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.
It gives you no retroactive history at connection time, no guaranteed latency figure, and no ability to act inside your pharmacy system. Those follow from the same choices that make it safe. Better to know now.
Attergo Integrations is the spine described here. Book a demo and we will walk the pipeline end to end, dead letter queue included.