DataScan Pharmacy Software (WinPharm) Integration Guide

DataScan's own site calls the product "Datascan Pharmacy Software". The name WinPharm comes from software review sites such as Capterra; this guide uses both names for the same product.

If you run an independent pharmacy on DataScan pharmacy software (WinPharm), or you build software that pharmacies on WinPharm would buy, the first integration question is simple: what can I plug into, and how? DataScan's public pages answer part of it. They name the standards (APIs, HL7 and NCPDP SCRIPT) and list more than 70 named partners by category. They do not publish an API reference, a list of events, or field-level specs. So any plan that depends on WinPharm sending your app a specific event, or accepting data back, starts with a conversation with DataScan.

This guide sets out what DataScan documents today, what it does not, what that means for nine common use cases, and the exact questions to ask DataScan before you commit budget. Every claim about WinPharm links to the DataScan page it came from. We read each one on November 13, 2026.

What does DataScan publicly document about WinPharm integration?

DataScan publicly documents the interface standards it uses, its partner names and a few built-in features of Datascan Pharmacy Software. DataScan's Software Interfacing page says its interfaces use "APIs and industry standards like HL7 and NCPDP", and that WinPharm can "use HL7 or NCPDP SCRIPT standards to exchange data securely" with "e-prescribing systems, EHRs" and other systems. The same page lists partners in 19 categories.

For what NCPDP SCRIPT covers and how its messages work, see our NCPDP SCRIPT standard guide.

• ePrescribing: Surescripts.
• Switch vendors (the networks that carry claims to payers): Change Healthcare, Relay Health (McKesson) and RXLinc.
• Reporting and data feeds: Mevesi, Macro Helix, 340 Basics, IQVIA, Asembia, Aquestive, Aventi Health, Cover My Meds and Scriptera.
• Adherence: FDS Amplicare, CPESN, Outcomes MTM, Carepoints and Prescribe Wellness.
• IVR: AIS, Digital Pharmacist and Medtel Communications.
• eMAR (medication records used by care facilities): ACCUflo, QuickMAR and Precision Care.
• Also listed: packaging, robots, pill counters, delivery, shipping, faxing, card processing, reconciliation, the Medi-Span drug database and 23 wholesalers.

The page also says two things that shape every project. "Custom pharmacy software interfacing integrations are quoted upon request." And "new vendor integrations come from our clients, not from individual vendors themselves." So a new integration usually starts with a pharmacy asking DataScan for it.

Other DataScan pages add product facts. The home page says "Medication Synchronization built-in", that a scheduler runs auto-refills, Med Sync, prescriber refill requests and patient texts, that "queue-based workflow moves each prescription through the stages you set", and that Datascan "connects to near 100 third-party systems". The interfacing page says "over 100 third-party systems". The inventory page lists "Free EDI with all vendors" for wholesaler ordering and price updates, plus automatic purchase orders. The Importance of Pharmacy Software (updated January 27, 2026) describes built-in med sync, refill reminders by text, email and app, and an adherence dashboard for hypertension, hyperlipidemia and diabetes. A DataScan article from October 2025, Does Pharmacy Software Have an API, says "Datascan's API allows pharmacies to extract and analyze data however they choose."

What is not publicly documented?

DataScan does not publicly document an API reference, endpoints, a sandbox, field specs, a rejection event for outside apps, or a way to write PA status back into Datascan Pharmacy Software. Those are the details a developer needs to scope a build. On the pages above, and in searches of datascanpharmacy.com on November 13, 2026, we found:

• No public API reference, endpoint list, sandbox or developer program. The API article describes the API's purpose, not its contents.
• No list of HL7 message types or NCPDP SCRIPT transactions WinPharm sends or receives.
• No documented event that sends a claim rejection to a third-party application. That includes NCPDP reject code 75, "Prior Authorization Required" (listed that way in, for example, Medi-Cal Rx Appendix D).
• No documented way for an outside app to write a prior authorization (PA) status back into WinPharm.
• No description of what the Cover My Meds data feed carries. The interfacing page lists it under Reporting/Data Feeds, and the site menu links to CoverMyMeds, with no detail.

A gap in the public pages does not prove the capability is missing. DataScan quotes custom interfaces on request, so some of these may be possible. The only way to know is to ask, and the questions near the end of this guide are written to get specific answers.

What can you build with WinPharm? Nine use cases

With Datascan Pharmacy Software (WinPharm), e-prescribing, wholesaler ordering, med sync, refill reminders and adherence already work inside WinPharm or through listed partners. Anything that needs WinPharm to push an event to your own app, or accept data back, needs DataScan to confirm it first. PA automation from rejections is the hardest of the nine.

Business value is the typical goal for each use case, not a measured result. Timelines are a typical build estimate, after DataScan confirms the interface. They do not include DataScan's own quoting or delivery time. Where no documented path exists, we give no estimate.

1. PA automation from rejections

2. E-prescribing intake

3. Refill reminders and outreach

4. Inventory and ordering feeds

5. Med sync

6. Adherence programs

7. Clinical services and MTM

8. Analytics and reporting

9. EHR and clinic coordination

All nine use cases compared

*Typical build estimate, after DataScan confirms the interface.

Why PA automation from rejections is the hard one

PA automation from rejections is the hard use case because it needs two hand-offs DataScan does not document: Datascan Pharmacy Software passing a claim rejection to your app, and accepting PA status back. Everything else in the path, the switch, the payer and the queue, is already described.

Most teams want this workflow. A claim goes out through the switch. The payer rejects it with code 75. WinPharm hands the rejection to your app, your app starts the PA, and when the payer decides, the status flows back into WinPharm so the technician sees it next to the prescription.

The first half is partly documented. DataScan describes queue-based workflow and names the switch vendors, but does not say how rejected claims are handled. The two hand-offs that make the rest automatic are the ones DataScan does not describe: a rejection event your app can receive, and a status your app can write back. Until DataScan confirms both, with fields and delivery method, treat the automated version as unproven for WinPharm.

Workarounds that use only what is documented

If DataScan cannot offer a custom interface yet, you can still integrate through routes it already documents: a listed partner that connects to Datascan Pharmacy Software, the e-prescribing and claim switch networks, or an existing data feed. Each route below relies only on what DataScan or the standards describe.

1. Staff-assisted workflow. A technician works WinPharm's rejected-prescription queue, starts the PA in the payer's or a PA network's portal, and records the outcome in WinPharm. Your software can still help with a PA tracker, reminders to chase the prescriber and a daily list of open PAs, none of which needs an event from WinPharm.
2. Ask your switch vendor. Rejections come back through the switch (Change Healthcare, Relay Health or RXLinc for WinPharm pharmacies). Ask your switch whether it offers a copy of rejected responses to an approved third party. We have not seen this documented for WinPharm sites, so treat it as a question, not a plan.
3. Data feeds and reports. DataScan lists nine reporting and data-feed partners and says reporting options are "endless". A scheduled feed or report of rejected claims can drive a next-day work list. A next-day list is slower than an event, and for many pharmacies it is enough to cut missed PAs.
4. Use a listed partner. If a partner on the DataScan list already does what you need, such as an adherence platform or an IVR vendor, starting with that partner is usually faster than a new custom interface.

Questions to ask DataScan before you build

Before you build, ask DataScan in writing whether an API reference, sandbox and test data exist, which events and write-backs are supported, how data feeds work, what agreements and consent it needs, and what a custom interface costs. Ask for written answers; each question is phrased so a yes must come with specifics.

1. Can WinPharm send a PA-required rejection (NCPDP reject code 75) to a third-party application? With what fields, and with what delivery options (API call, file, HL7 message)? How soon after the claim response?
2. Can a third-party application write a PA status or note back to the prescription in WinPharm? Which fields, and does a pharmacist see it in the rejected queue?
3. What does the Cover My Meds data feed listed on your interfacing page carry, in which direction, and how often?
4. Is there an API reference for the API described in your October 2025 article? Which data can it read, and can it write anything?
5. Which HL7 message types and versions does WinPharm send and receive, and with which EHR or clinic systems is that live today? (Our EHR integration work starts from this answer.)
6. Which NCPDP SCRIPT transactions does WinPharm support beyond new prescriptions, such as renewals, changes and cancels?
7. Is there a test system or sandbox for vendors, and who provides test data?
8. For a data feed: what format, which fields, how often, and can it be filtered by store?
9. Does the pharmacy need to request the integration, and what consent or agreement does DataScan need from the pharmacy and from us?
10. Will DataScan sign a BAA with us, and what patient consent or pharmacy authorization does the interface need?
11. How is a custom interface priced and how long do your recent ones take from quote to live?

How does PioneerRx compare?

PioneerRx, another US pharmacy system, has published how its CoverMyMeds link works. Its blog post of April 24, 2019 says the system "provides easy access to the CoverMyMeds portal", so staff can work rejected claims there from within PioneerRx, and that its IntelligentPA tool acts "if a claim remains unresolved for more than 10 minutes", starting the PA and notifying the provider.

That is the level of detail missing for WinPharm: a named trigger, a time, and where the work happens. DataScan may support something similar. Its public pages do not say so. If PA automation from rejections is your main goal, ask DataScan the first three questions above before you compare systems on anything else. The PioneerRx post is from 2019, so check it is still current too.

Known caveats

The main caveats are that DataScan's partner list does not say what each interface does, its API article gives no endpoints, third-party directories list features DataScan does not confirm, public pages change, and the timelines here are typical build estimates that start only after DataScan confirms the interface.

• DataScan's partner list names partners. It does not say what each interface does or which direction data moves.
• The API article is written for pharmacy owners. It gives no endpoints, so it cannot be used to scope a build.
• Third-party software directories list WinPharm features that DataScan's own pages do not. We left those out of this guide. Confirm any feature with DataScan.
• Public pages change. Every fact here was read on November 13, 2026.
• Timelines in this guide are typical build estimates, after DataScan confirms the interface. They do not include DataScan's own quoting or delivery time, and use cases with no documented path have none.

Talk to us about a Datascan Pharmacy Software integration

We can scope a Datascan Pharmacy Software integration with you. We can work through the questions above, map each use case to a documented route, and plan the build around what DataScan confirms. See our pharmacy integration services, our prior authorization integration work if PA is your starting point, or our HL7 integration services for EHR links. To set up a scoping call, get in touch.

Related guides: CoverMyMeds API integration and ModMed API documentation.