A pilot exists to falsify a claim, not to be impressed by one. The claim is that reading your prescription events in real time will show you money you are losing that you cannot currently see, and that the numbers will be accurate enough to act on.
Four weeks is enough to test that. Here is what each week involves, what failure looks like, and where it usually goes wrong.
Week 0: paperwork and a credential
Three things happen before any data moves.
The BAA is signed. No PHI moves before it exists.
A per-store credential is issued. In PioneerRx this is configured once per store so events are posted to an endpoint over HTTPS. Nothing is installed on a workstation, nothing scrapes a screen, and no dispensing workflow changes.
You name one person who owns the pilot. This is the requirement most often skipped and the one most correlated with a pilot going nowhere. It does not have to be the owner. It has to be someone who will look at a screen twice a week and is allowed to say “that number is wrong”.
What goes wrong here: the credential is configured on the wrong store, or on one store when you assumed all of them. If you run multiple locations, decide deliberately whether the pilot is one store or all of them, because a single store is a cleaner test and a five-store rollout answers a different question.
Week 1: events arrive and are archived
Success this week is unglamorous: events show up, they are archived exactly as received, and you can see them in a feed with the store, the drug, the payer and the amount.
Note what is being tested. Not the analytics. The plumbing. If the plumbing is wrong everything downstream is decoration.
What goes wrong here:
Field names vary between store configurations. Pharmacy systems emit differently depending on version and setup, which is why the adapter resolves each field from candidate names, rejects nothing for being unfamiliar, and records every field the mapping did not claim instead of discarding it. Variance found in week one is mapped against your actual traffic, typically within a day. This is the integration architecture doing its job, and it is the reason a payload change can never silently drop your data.
Volume is not what anyone expected. Either far lower, which usually means the credential is scoped more narrowly than you thought, or higher, which usually means event types you did not have in mind are included.
Store codes are missing or inconsistent, which matters immediately if more than one location is connected.
Week 2: cost gets into the system
This is the week that decides whether the pilot produces anything worth reading, because margin is only as good as the acquisition cost behind it.
Wholesaler invoice data is imported and matched to what you dispensed. Where an invoice exists for that NDC, margin is computed against it and labelled as invoice-based with high confidence. Where it does not, NADAC is used as a fallback and the fill is labelled as indicative rather than presented as your cost. Where neither exists, no margin is shown at all, and the fill is flagged as needing a cost rather than quietly reported as profitable.
What goes wrong here:
Coverage is lower than expected. You will see fills with no margin. This is the system being honest rather than broken, but it can be uncomfortable in a demo, so it is better said now.
NDC formats do not match. The same product appears as a 10-digit code in one system and 11 digits in another. Normalisation handles most of it; the residue is manual.
Package size versus dispensed quantity. Your invoice prices a bottle of 90 and the fill dispensed 30. Scaling is arithmetic, but it depends on the package quantity being right in the reference data, and sometimes it is not.
Invoices only exist as PDFs, or only inside a wholesaler portal that the person running the pilot cannot access. Sort out that access in week 0 if you can.
340B or other contract pricing. If some of your volume runs on contract pricing, the invoice cost is not the applicable cost, and you should exclude that population from the pilot’s conclusions rather than let it distort them.
Week 3: numbers you can argue with
Now the useful work. Take ten fills and try to break them.
Choose deliberately: a cheap generic, a brand, one with a large copay, a reversal, one with no invoice on file, and two you already suspect lose money. For each, write down independently what you believe the pharmacy received and what the drug cost. Then compare.
Every fill shows revenue, cost, the basis the cost came from, a confidence level and a note explaining any caveat. When your number and ours disagree, the cause is almost always one of three things: a fee that was not known at adjudication, a cost basis that is NADAC rather than your invoice, or a package-size mismatch.
Spend an hour on this with the person who owns the pilot. It is the single highest value hour in the four weeks, and a vendor unwilling to sit through it is telling you something.
What goes wrong here: the numbers disagree and nobody chases why. A disagreement traced to its cause is a pilot succeeding. A disagreement shrugged at is a pilot that will quietly be abandoned in week six.
Week 4: decide
Write the pass criteria in week 0, not in week 4, or the decision becomes a feeling. Reasonable criteria look like:
- Events arrive reliably, and a deliberate outage is backfilled without duplicates.
- Cost coverage reaches a level you named in advance.
- Of the fills flagged as losing money, the ones you check are genuinely losing money.
- At least one thing was found that you would not otherwise have seen, and someone could have acted on it.
- The person who owned the pilot is willing to keep doing it.
That last one is not a soft criterion. A queue nobody works is worth nothing at any price.
What we will not do during a pilot
Worth stating, because it removes most of the risk people are actually worried about.
- Nothing is written back into your pharmacy management system. The integration is read-only.
- No dispensing workflow changes. Nobody at the counter has a new step.
- No hardware, no workstation software.
- No contact with your patients, ever.
- No change to how or when you order from your wholesaler. The product tells you something; you decide what to do.
What we need from you
- A named owner, and roughly two hours a week of their time.
- Access to wholesaler invoice data.
- One hour in week 3 for the disagreement session above.
- Permission to ask you what a field means when your payload contains something we have not seen.
Scope the pilot to one question
The platform is eight products on one event spine: Margin, Billing, Audit, Authorizations, Inventory, Compliance, Intelligence and Integrations. A four week pilot should still test one claim, and margin accuracy is the right one, because every other product inherits its credibility from the same data foundation the pilot is stress testing. Prove that the events arrive completely, that cost resolves correctly, and that the flagged fills are genuinely losing money, and you have validated the spine everything else runs on.
Evaluations begin on PioneerRx, the reference integration. On another pharmacy system, the engagement starts with integration scoping, and the pilot follows the adapter.
How to end it
If the answer is no, say so and you receive an export of your normalized events while we delete what we hold. There is no notice period on a pilot and no obligation at the end of it.
A four week evaluation that ends in a clear no is a good outcome. A long evaluation that ends in a purchase somebody regrets is not, and the pilot is structured so that cannot happen: written criteria, your numbers, and a decision you can defend to yourself.