Pharmacy management software connects to clinical and payer systems through three separate integrations that are often confused for one. The prescriber-to-pharmacy link carries new prescriptions, refills, changes and cancellations over the NCPDP SCRIPT standard, routed across the Surescripts network. The pharmacy-to-PBM link is a different standard entirely — the NCPDP Telecommunication Standard — and handles eligibility checks, claim adjudication and pricing in near real time at the point of dispensing. The third link, pharmacy back to the clinical record, is the one most often missing: it carries dispensing and medication-history data into the EHR over HL7 v2 or FHIR so a prescriber can see what was actually filled rather than what was ordered. A project described as “integrating our pharmacy software” almost always means one of these three, and scoping the wrong one is the most common source of surprise cost.

What Does “Pharmacy Integration” Actually Mean?

I get some version of this question constantly, and it’s usually asked as if pharmacy integration were one thing. It isn’t — it’s three distinct connections, each running over a different standard, each with a different counterparty on the other end:

  • Prescriber → pharmacy, over NCPDP SCRIPT, routed through Surescripts
  • Pharmacy → PBM, over the NCPDP Telecommunication Standard, for claims and eligibility
  • Pharmacy → clinical record, over HL7 v2 or FHIR, for medication history flowing back to the EHR

Every scoping conversation that goes sideways starts with one of these three getting quietly assumed instead of confirmed. Nail down which one (or ones) you actually need before anyone estimates a timeline.

How Does a Prescription Get to the Pharmacy?

This is NCPDP SCRIPT territory — the same standard and transaction set (NewRx, RefillRx, CancelRx, ChangeRx) I go through in detail in the full Surescripts certification guide. If you’re scoping this specific leg, that’s the deeper resource; the short version is that it’s a certification process through Surescripts, not a self-serve API.

How Does a Pharmacy Connect to a PBM?

This is a genuinely different standard from SCRIPT, and conflating the two is where most confusion in this space actually starts. Pharmacy-to-PBM connectivity runs on the NCPDP Telecommunication Standard, and its core interaction is claim adjudication — the pharmacy submits a claim at the point of dispensing, and the processor or PBM responds within seconds with a paid or rejected decision, carrying coverage, patient responsibility, and if rejected, a coded reason.

One detail worth flagging for anyone scoping a longer-term build: NCPDP’s F6 standard is replacing the long-standing D.0 version, with a compliance deadline of May 2028. F6 expands the data model to better support specialty and high-cost therapies, real-time benefit and formulary communication, and controlled-substance handling. If you’re architecting anything meant to last past the next couple of years, build with that transition in view rather than assuming D.0 is permanent.

How Does Dispensing Data Get Back Into the EHR?

Here’s the link that’s commonly missing, and it’s a real clinical gap when it’s absent. A prescriber’s EHR shows what was ordered — a MedicationRequest, in FHIR terms — but not necessarily what was actually filled or taken. Closing that gap means pulling dispensing data back into the clinical record, typically via HL7 v2 feeds or FHIR’s MedicationDispense resource, with MedicationStatement serving as the consolidated summary of everything ordered, dispensed and administered for a patient over time.

Without this link, a prescriber is working from what they wrote, not from what actually happened at the pharmacy counter — and that gap is exactly what drives the medication-reconciliation problem I cover in more depth in a dedicated post on reconciling prescribed, dispensed and taken as three different datasets.

Which HIPAA-Compliant Solutions Connect Pharmacy to Provider Networks?

Architecturally, this connectivity runs through a handful of patterns: interface engines that route and transform messages between systems, direct point-to-point connections for simpler cases, and network intermediaries like Surescripts sitting between prescriber and pharmacy. None of these are automatically “HIPAA compliant” just by existing — that status depends on the same things it always does: a signed business associate agreement with every vendor in the path, encryption in transit and at rest, and audit logging that actually records who accessed what and when. The architecture pattern you choose is an engineering decision; whether the resulting system is compliant is a separate, ongoing operational one.

Where These Projects Actually Go Wrong

The most common failure I see is scoping exactly one of the three connections above and discovering mid-build that the actual requirement needs two, or all three. A close second: assuming everything moves over FHIR when the counterparty — a PBM, in particular — only speaks NCPDP. Confirm which standard your specific counterparty actually expects before you architect anything, because “we’ll use FHIR for everything” is a design decision that only works when the systems on the other end agree to it.

Next Steps

If you’re scoping pharmacy connectivity for a custom EHR build, the first real question isn’t which vendor or which API — it’s which of the three connections above you actually need, because that decides the standard, the counterparty, and the realistic timeline. Our pharmacy integrations team has built all three; talk to us about which one fits what you’re actually trying to do.