IT support built for pharmacies

Where your software vendor stops and we start

Every pharmacy we take on has had the same afternoon. Something is broken, you ring the software vendor, and they tell you it is a network problem. You ring your IT company, and they tell you it is a software problem. Nobody is lying. The fault genuinely sits on the seam between them, and you are the one standing at the counter holding both phones.

That seam is most of our job. Your dispensing system vendor owns the application, the updates and the clinical side of it. We own everything it runs on and everything it talks to: the server the database lives on, the network between that server and the terminals, the workstations, the label printers, the scanners, the internet connection and the backups. When the answer is genuinely on their side, we get on the call with them and stay on it, rather than handing you a ticket number and a vendor phone number.

What we support, and what that actually means

We support PioneerRx, Rx30 and LibertyRx, and we are familiar with PK Software's Compounder and Parata automation.

What that means in practice is less about the application and more about what sits underneath it. These are database-backed systems: a server holds the data, terminals at the counter talk to it constantly, and the things that go wrong are almost always about that conversation rather than the software itself. A workstation on failing wifi, a switch with a dying port, a server running out of disk, an antivirus product that decided the database looked suspicious — all of these present to your staff as "the pharmacy system is slow", and none of them are fixed by reinstalling the pharmacy system.

Automation hardware adds another layer. A counting or packaging machine is a computer with a specific job, and it needs the same patching, network reliability and monitoring as anything else on your floor, plus a relationship with a vendor who supports it.

The five things that actually break

After enough pharmacies, the list stops being a surprise:

1. Antivirus that has not been told what to leave alone. Security software scanning a live dispensing database will make the whole system crawl, and occasionally do worse than that. The exclusions have to be set deliberately and then checked after every product change or upgrade, because a vendor update can quietly reset them. We wrote up what actually works for antivirus in a pharmacy, exclusions included.
2. Label printers. The most common support call in any pharmacy, and rarely an interesting fault — a driver, a setting, a worn print head. What makes it a five-minute problem instead of a lost afternoon is having the configuration documented and a spare already set up.
3. Backups nobody has restored. A backup that runs is not a backup that works. A dispensing database needs to be backed up in a way that understands it is a database, verified by an actual test restore, and kept somewhere ransomware cannot reach from the network it is protecting.
4. One internet connection. If your system reaches anything outside the building — and almost all of them do, for claims, e-prescribing or the software itself — a single connection is a single point of failure sitting between you and dispensing. A second connection that fails over automatically is one of the cheapest pieces of resilience a pharmacy can buy.
5. Workstations kept too long. A terminal at the counter running an operating system that stopped receiving security updates is both a compliance problem and a slow-fill problem. It is also the easiest thing on this list to plan for, if somebody is tracking the ages.

Long-term care, closed-door and multi-site

A closed-door or long-term care pharmacy has a different risk profile from a retail counter. There is no walk-in queue to watch, which paradoxically makes outages easier to miss and more expensive when they happen, because the deadline is a delivery run rather than a person waiting. Cycle fill schedules, facility interfaces and delivery timing all mean that "we will look at it tomorrow" is not an acceptable answer for problems that a retail pharmacy could survive overnight.

Groups with several locations get the most out of this. Every site built to the same standard means any engineer already knows how yours is configured, and monitoring them together means a problem showing up at three sites gets recognised as one problem rather than three tickets.