7 Questions to Ask Before Choosing a Kroll Automation Vendor

Evaluating pharmacy automation vendors is harder than it looks. Most vendors demonstrate well, use confident language about their capabilities, and share metrics that are designed to be impressive rather than informative.

The questions below are designed to cut through the positioning and get to the operational reality. Some of these questions will make vendors uncomfortable. That discomfort is useful information.

1. Is this native Kroll integration or RPA?

This is the most important technical question. Robotic process automation (RPA) tools automate Kroll by controlling the user interface — clicking through fields the way a human would. Native integration communicates with Kroll at a deeper level, not through the screen.

The practical difference: RPA breaks when Kroll updates its UI. Native integration does not. Kroll releases platform updates regularly, and each update is a potential disruption point for RPA-based automation.

What to listen for: A vendor that cannot explain specifically how their system communicates with Kroll is probably using RPA. Listen for language like “we automate the Kroll interface” or “our bot fills in the fields” — these are RPA descriptions. A native integration vendor will be able to explain that their system reads and writes Kroll data directly.

Follow-up: “When Kroll released their last major update, what happened to your automation? How long was it offline?“

2. Where is patient data stored?

Prescription data is personal health information regulated under PHIPA and PIPEDA. Canadian pharmacies are accountable for how vendors handle that data — including where it is stored.

The standard you should require: patient data stored at rest in Canadian data centres, not in the United States or elsewhere. Any vendor who cannot confirm Canadian data residency in writing is a non-starter for a Canadian pharmacy.

What to listen for: Vague answers about cloud infrastructure are a red flag. “We use Amazon Web Services” is not an answer — AWS has Canadian and US data centres, and your question is specifically which one. Require a written commitment to Canadian data residency in your contract and data processing agreement.

Follow-up: “Can you confirm in writing that all patient data — including data at rest and data in transit — is stored in Canada?“

3. How long does implementation take?

Implementation timelines vary dramatically across vendors. Some can have a pharmacy live within one to two weeks. Others require a month or more of configuration, training, and testing before the first prescription is processed automatically.

The timeline matters for two reasons: the practical question of when you get the benefit you are paying for, and the operational question of what happens to your pharmacy while implementation is in progress.

What to listen for: Ask specifically about the steps between signing and go-live. A credible vendor can walk through each phase (kickoff, configuration, QA, go-live) with realistic timelines. Vague answers about “a few weeks” or “it depends” without detail are a sign the vendor does not have a mature onboarding process.

Follow-up: “Can you walk me through exactly what happens between the time we sign and the time the first fax is processed automatically?“

4. Is there a waitlist?

Some vendors have more demand than they can onboard at a given time. That means even after you sign, you wait before onboarding begins.

A waitlist is not inherently disqualifying, but you should know about it before you budget. If a vendor has a waitlist of four to eight weeks, your actual go-live timeline is longer than their “implementation takes four weeks” answer suggests.

What to listen for: Ask directly: “If I sign today, when does my onboarding begin?” A vendor without a waitlist will answer that question immediately. A vendor with one will hedge.

5. What happens when the system encounters an exception?

No automation system processes 100% of prescriptions without issue. Ambiguous faxes, prescribers not in your system, drugs not in your catalog — these are routine edge cases in any pharmacy. The question is not whether exceptions will occur but what happens when they do.

A well-designed system flags exceptions immediately, routes them to your staff with the original document and a clear description of the problem, and lets your team resolve them in seconds. A poorly designed system either guesses on low-confidence inputs (introducing errors) or fails with no clear resolution path.

What to listen for: Ask the vendor to walk you through what happens when a fax is unreadable or a drug is not in catalog. Ask to see the exception interface. Ask what information your staff receives when something is routed for review.

Follow-up: “Can you show me what an exception looks like from my team’s perspective?“

6. How do you handle Kroll updates?

Kroll releases platform updates periodically. For RPA-based systems, these updates can break automation scripts. For native integrations, they generally do not. But even native integrations may require attention when Kroll makes significant changes.

The question is not whether the vendor handles updates — the question is how, how quickly, and who bears the cost.

What to listen for: A vendor who says “our system adapts automatically” is using native integration and has thought about this. A vendor who says “our team will fix it within [X] days” is using RPA and is giving you a service-level commitment for a known disruption point. Both answers have implications; the first is preferable.

Follow-up: “What is your track record on Kroll update response time? Can you give me an example of a recent update and what happened?“

7. What compliance documentation can you provide?

For Canadian pharmacies, the minimum documentation you should require before signing:

• Data Processing Agreement (DPA): A formal agreement covering how the vendor processes patient data on your behalf, your rights to audit, and their obligations under Canadian privacy law
• Subprocessor list: Which third parties have access to patient data, and what DPAs exist with those subprocessors
• Privacy policy: How the vendor handles personal information
• Data residency confirmation: Written confirmation of where patient data is stored

If a vendor hesitates to provide any of these, or describes them as non-standard requests, that is a compliance risk that extends to your pharmacy.

What to listen for: A vendor with mature compliance practices will have these documents ready and will volunteer them as part of the sales process. You should not have to fight for a DPA.

---

AutoRx is available to answer all seven of these questions directly — with documentation.

Book a demo or review our Trust Center, Security, and Subprocessors pages to start your evaluation.