PillPilot journal

Why we run on top of your pharmacy system

Why PillPilot uses the pharmacy system like a technician instead of requiring a separate integration.

Architecture layersSame screens, explicit guardrails
  1. 01

    Read the existing PMS

    Use visual and accessibility signals already on screen.

  2. 02

    Take the same action

    Work through the fields and controls the team already uses.

  3. 03

    Confirm the result

    Check the screen after each meaningful action.

  4. 04

    Stop when uncertain

    Leave unreadable or ambiguous work for a person.

  5. 05

    Record the outcome

    Keep the write and handoff attributable.

The article explains both the flexibility and the honest maintenance tradeoff.
In this article6 sections

TL;DR: PillPilot is designed to work through supported pharmacy-management-system workflows rather than requiring a custom backend integration for each one. Its vision and accessibility layer reads the application and enters data through the same interface pharmacy staff use. Supported systems and workflows still require validation before go-live.

The pharmacy management system matters when evaluating automation because every product supports a different set of systems and workflows. A direct API connection, interface-based automation, and outsourced entry also create different implementation, maintenance, and data-handling requirements.

PillPilot reduces dependence on custom PMS APIs by working through supported application interfaces. The approach does not make every PMS or workflow automatically compatible; each supported workflow is validated against the specific system and version used by the pharmacy.

Why do pharmacy system integrations take so long?

Pharmacy system integrations can take months because every PMS has a different data model, interface, and vendor approval process. PioneerRx, PrimeRx, BestRx, EnterpriseRx, QS/1, and ComputerRx each have their own screens and their own way of representing a SIG or a claim. Our team has shipped pharmacy software on the vendor side, including at the company behind one of these systems, and our experience there was consistent: a direct integration to a single PMS can require months of engineering, in addition to the vendor's approval process, which gates the API access you'd need in the first place. Building and maintaining integrations to multiple systems as each changes requires ongoing work.

That is why an automation vendor's supported-system list, current workflow coverage, validation process, and vendor-access requirements matter during evaluation.

Is e-prescribing standardized inside the pharmacy system?

No. E-prescribing is standardized on the way into the pharmacy, but not inside the PMS. Prescriptions arrive as NCPDP SCRIPT messages, mostly over the Surescripts network. Surescripts reports 30.5 billion health-intelligence transactions in 2025, including e-prescribing, benefit, prior-authorization, medication-history, clinical-message, and other exchanges. Federal policy enforces e-prescribing standards: CMS requires SCRIPT for Medicare Part D e-prescribing, and ONC's health IT certification criterion (§ 170.315(b)(3)) requires SCRIPT version 2023011 by the end of 2027. That's why, per ONC, 92% of prescribers e-prescribed in 2020, up from 7% in 2008.

But SCRIPT stops at the pharmacy's front door. It standardizes the message between prescriber and pharmacy: NewRx, RxRenewal, CancelRx. It says nothing about what happens inside the PMS: how the fill gets typed, coded, checked, and billed is each vendor's own data model, and there is no NCPDP standard for writing into each vendor's internal data model. The incoming transaction is standardized, while the downstream entry workflow remains vendor-specific.

What does it mean to run an AI agent on top of a PMS?

Running on top of a PMS means the agent works through the application the way a person does instead of writing directly to its database. For supported workflows, it reads the e-script, opens Data Entry, enters the drug, SIG, quantity, days supply, refills, and prescriber, and submits through the PMS interface. The normal entry path allows configured PMS checks to run where that workflow ordinarily invokes them. PillPilot verifies defined postconditions and is designed to stop when a required screen or result cannot be read reliably.

This can reduce the amount of custom integration and migration work, but onboarding time depends on the PMS, workflow scope, environment, and validation requirements.

Isn't this just screen scraping?

A vision and accessibility layer can identify fields by visual labels, structure, and behavior, while coordinate-only screen automation replays fixed locations and keystrokes. Coordinate-only automation is especially sensitive to moved buttons, new dialogs, different screen sizes, and changed tab order.

Visual and accessibility signals reduce dependence on fixed coordinates, but they do not eliminate change risk. Labels, controls, prompts, and workflow structure can all change, so supported workflows still need detection, regression testing, and defined stop conditions.

The "accessibility" half of the layer matters too. Desktop applications expose a structured tree of their controls (names, roles, values) for assistive technology like screen readers, and that structure can supply information that pixel coordinates do not. Some applications expose incomplete or changing accessibility data, which is why PillPilot combines signals and validates each supported workflow.

A PMS release can rename a field, add a required prompt, or restructure a workflow. PillPilot is designed to verify defined states during supported workflows and stop for human review when a required state cannot be confirmed.

What are the four ways to automate pharmacy data entry?

The four main approaches are API integration, legacy RPA, a vision-layer agent, and outsourced data entry. The implementation and risk profile of each approach depends on the specific product and contract.

API integrationLegacy RPAVision-layer agentOutsourced data entry
Time to go liveDepends on API access, mapping, testing, and vendor approvalDepends on screen count, scripting, and testingDepends on PMS, workflow scope, environment, and validationDepends on access setup, staffing, and training
PMS coverageSystems and workflows with an available, authorized APIScreens and variants explicitly scriptedSystems and workflows the vendor has validatedSystems the workforce can securely access and operate
Change sensitivityAPI contracts, versions, and permissions can changeCoordinate and selector changes can break scriptsVisual and accessibility signals can change; detection and regression testing remain necessaryPeople adapt, but procedures and training must be updated
PMS checksDepends on the write path and implementationDepends on the screens and steps automatedUses the normal PMS path for each supported workflow; required outcomes still need verificationDepends on permissions, procedure, and supervision
Implementation workMapping, testing, security review, and vendor approvalScripting, testing, and ongoing maintenanceWorkflow validation, environment setup, and ongoing regression testingAccess, workforce, training, quality controls, and supervision
PHI reviewVerify transmitted fields, storage, access, subprocessors, and BAAVerify runtime access, credentials, logs, screenshots, subprocessors, and BAAVerify visual and structured inputs, retention, access, subprocessors, and BAAVerify workforce access, location, systems, supervision, and BAA

What is the tradeoff of working through the PMS interface?

The tradeoff is speed at the individual action level: the agent moves at the speed of the software interface, not at the speed of a raw database write. So let's put a number on the ceiling. Take a hypothetical busy independent doing 300 scripts a day. Even at a full minute of interface time per script, that is 300 minutes, or five hours, of active processing. Whether that is sufficient depends on concurrency, arrival peaks, exception rate, and operating hours.

A backend connection can be useful where an authorized API materially improves reliability or throughput. PillPilot starts with the existing PMS interface for supported workflows and evaluates additional connections where they add value.

Why is this approach a practical default for independent pharmacies?

This approach is a practical default because an independent or community pharmacy can use automation while reducing the need for a custom backend integration. Running through the PMS interface can preserve the pharmacy's existing workflow and configured checks, subject to system-specific validation and pharmacy oversight.

Sources3 linked sources
Reference status3 linked sources
Sources checked

This article describes PillPilot's current architecture and design boundaries. Supported systems and workflows require environment-specific validation before go-live.

Inside the PMS you already run

See what PillPilot takes off the counter.

PillPilot finishes prescription data entry, then makes the outbound refill and pickup calls that follow, with a pharmacist on every exception.

See how it works
FAQ

Questions worth asking.

Does PillPilot break when my PMS updates?

A PMS update can change labels, controls, prompts, or workflow structure. Visual and accessibility signals reduce dependence on fixed coordinates but do not eliminate change risk. PillPilot uses defined checks for supported workflows and is designed to stop for human review when a required state cannot be confirmed.

Is a vision AI agent the same as RPA or screen scraping?

Not exactly. Coordinate-only automation replays fixed locations and keystrokes. A vision and accessibility layer can use visual labels, control structure, and behavior, reducing sensitivity to layout alone. Either approach still requires system-specific testing and maintenance.

Why doesn't PillPilot use the PMS's API?

NCPDP SCRIPT standardizes prescription transactions arriving at the pharmacy, not every vendor's internal data model or write interface. Authorized APIs can be valuable where available. PillPilot reduces dependence on custom APIs by working through supported PMS interfaces and validates each workflow before go-live.

Does working through the interface bypass safety checks?

For supported workflows, PillPilot is designed to use the PMS's normal entry path so configured checks can run where that workflow ordinarily invokes them. It verifies defined outcomes and stops for review when a required state cannot be confirmed. Pharmacy configuration and oversight remain authoritative.

Book a 20-minute call

Let your pharmacists be pharmacists.

PillPilot installs in two weeks and runs on top of the system you already use.