You are building a product that needs to send prescriptions electronically, and someone told you to "integrate with Surescripts." So you go looking for the Surescripts API, expecting a developer portal, a few endpoints, and a sandbox key. What you find instead is a national network with a certification program, a standards body called NCPDP, a separate and much harder requirement if you want to touch controlled substances, and a timeline measured in months. That gap between what you expected and what e-prescribing actually involves is where most teams lose their first quarter.

This guide maps the real terrain: why Surescripts is a network you connect through rather than an API you call, the NCPDP SCRIPT transaction set that carries prescriptions in both directions, the EPCS rules that make controlled-substance prescribing the hardest part of the project, and why certification and contracting - not coding - drive your schedule. If you have read our companion piece on the gap between NCPDP SCRIPT and FHIR MedicationRequest, this is the operational layer underneath it.

Surescripts is a network, not an API

The single most important thing to understand before you scope anything: Surescripts operates the dominant e-prescribing and health-information network in the United States. It is the connective tissue between prescribers, pharmacies, pharmacy benefit managers, and health systems. When a provider sends a prescription electronically, that message does not go straight from your software to a pharmacy's software. It travels across the Surescripts network, which routes it, validates it, looks up the pharmacy in a master directory, and delivers it to the right destination.

This matters for how you architect. You are not building point-to-point connections to thousands of pharmacy systems. You are connecting once, to the network, and the network reaches every pharmacy and prescriber already on it. The upside is reach. The cost is that you play by the network's rules: its certification process, its standards conformance, its directory model, and its contractual terms. There is no "just hit the endpoint" path. You become a certified participant or you connect through someone who already is.

Because Surescripts sits at the center of pharmacy workflows, the same network connection also unlocks adjacent value beyond writing prescriptions - eligibility checks, formulary data, and medication history all flow over it. We cover the commercial side of that in our look at the pharmacy marketplace and e-prescribing automation, but the technical point stands: one network, many transaction types.

NCPDP SCRIPT: the language prescriptions are written in

The messages that flow across the network are not arbitrary JSON. They follow the NCPDP SCRIPT standard, maintained by the National Council for Prescription Drug Programs. NCPDP SCRIPT is the e-prescribing equivalent of HL7 v2 for hospital interfaces or DICOM for imaging - a domain-specific standard that defines exactly how a prescription, a renewal request, or a cancellation is structured so that any conformant system can read it.

Most teams discover quickly that "e-prescribing" is not one transaction. It is a set of them, flowing in both directions, and a real integration has to handle the full conversation, not just the first message.

The transactions you will meet most often:

• NewRx - the new prescription itself, sent from the prescriber to the pharmacy. This is the one everyone starts with, and the one teams wrongly assume is the whole job.
• RxRenewal (renewal request and response) - the pharmacy asks the prescriber to authorize more refills; the prescriber approves, denies, or modifies. This round trip is where a lot of real clinical workflow lives.
• RxChange - the pharmacy requests a change to a prescription, often for formulary reasons, a generic substitution, or a prior-authorization issue, and the prescriber responds.
• CancelRx - the prescriber cancels a prescription already sent, and the pharmacy acknowledges.
• RxFill - the pharmacy reports back whether and when a prescription was dispensed, picked up, or not filled, closing the loop on adherence.
• Medication history (RxHistoryRequest / Response) - a query that returns a patient's filled-medication history aggregated across the network, invaluable for reconciliation and safety checks.

If you only implement NewRx, you have built a one-way fax with extra steps. The renewals, changes, and cancellations are what make the integration clinically usable, and they are the transactions that surface the most edge cases in certification.

The version migration you cannot ignore

NCPDP SCRIPT is versioned, and the version matters for compliance. For years the industry ran on SCRIPT version 10.6. CMS then adopted NCPDP SCRIPT version 2017071 for the Medicare Part D program, retiring 10.6, and Surescripts sunset 10.6 on its own network in 2021 as part of that migration. If you are building today, you build to the 2017071 era of the standard, not the older 10.6 messages you may still see referenced in older documentation. (A further transition, to SCRIPT version 2023011, is already on the CMS roadmap for a future compliance date, so treat the version as a moving target you re-confirm at the start of every project rather than a constant.) The practical takeaway: always verify the current required SCRIPT version against CMS and Surescripts guidance before you model a single message, because building to a retired version is a quiet way to fail certification.

EPCS: where e-prescribing gets genuinely hard

Sending a prescription for an antibiotic is one problem. Sending one for a Schedule II controlled substance - an opioid, a stimulant, certain sedatives - is a different and far stricter one. Electronic Prescribing of Controlled Substances (EPCS) is regulated by the DEA under 21 CFR Part 1311, and it is, in our experience, the single hardest part of any Surescripts-adjacent project.

The reason EPCS is hard is that the difficulty does not live in the message format - a controlled-substance NewRx is still an NCPDP SCRIPT message. It lives in the surrounding controls the DEA requires before a prescriber is even allowed to sign one. Four requirements drive most of the work:

• Identity proofing. Each prescriber's identity must be verified to a high assurance level (aligned with NIST Special Publication 800-63 standards) before they are issued credentials to sign controlled-substance prescriptions. This is a real-world identity-verification process, not a checkbox in your signup flow.
• Two-factor authentication. At the moment of signing, the prescriber must authenticate with two of three factors - something they know, something they have, something they are. A password plus a hardware token or biometric is a common pattern. This two-factor step is required for every controlled-substance signing event.
• Third-party certification or audit. The EPCS application itself must be verified by a qualified third party - a DEA-recognized certifying organization or auditor - to confirm it meets the regulation. You cannot simply self-attest that your software is compliant.
• Digital signatures and audit trails. The signing must produce a tamper-evident record, with logging that can withstand scrutiny. The audit trail is part of the regulation, not an optional nicety.

None of this is impossible, but all of it takes time and specialized partners, and it cannot be retrofitted easily late in a project. The identity-proofing and two-factor controls touch your authentication architecture directly, which is why we treat EPCS as a security-design conversation from day one - the same posture we describe in our healthcare API security guide. If controlled substances are in scope, plan the EPCS workstream first, not last.

Certification and onboarding are the real timeline

Here is the expectation gap that derails schedules. Teams budget for the engineering - parsing and generating NCPDP SCRIPT messages, handling the round trips - and assume that is the project. The build is real work, but it is rarely the long pole. The long pole is getting certified by Surescripts and onto the network.

The onboarding arc looks like this. First you choose your path: build directly to Surescripts certification yourself, or connect through a certified intermediary or an EHR that already holds certification. Then comes conformance testing, where your messages are validated against Surescripts' test scripts - and the edge cases here, especially around renewals and cancellations, are where unprepared teams stall. Then certification and contracting, which is the step that genuinely takes months: Surescripts certifies your software for each transaction type you support and signs network agreements with you. Finally, production enablement, where you appear in the network directory and traffic is turned on, often in controlled stages rather than all at once.

Plan your project plan around the certification step. We have watched teams hit a working sandbox in a few weeks and then spend the next several months in certification and contracting before a single live prescription moves. This is the same dynamic we see across regulated healthcare integrations - the pattern recurs in our guide to healthcare interoperability standards, where conformance and certification consistently outweigh the raw coding effort. Treat certification as a workstream with its own owner and milestones from week one, not as a formality you discover at the end.

Direct certification versus a certified intermediary

This is the architectural fork most teams face. You can pursue Surescripts certification directly, which gives you the most control and the deepest integration but carries the full weight of the certification and EPCS audit process. Or you can connect through a partner who is already certified - many EHRs and specialized e-prescribing vendors expose their certified connection to applications built on top of them - which gets you to market faster but means you inherit their constraints, their roadmap, and often their pricing model.

There is no universally right answer. A standalone e-prescribing product with controlled-substance ambitions usually needs to own its certification eventually. A feature inside a broader clinical product often ships faster, and at lower risk, by riding a certified intermediary first. What you should not do is pick this fork by accident. Decide it deliberately, with the certification timeline and the EPCS requirements both on the table, because switching paths late is expensive.

Eligibility, formulary, and medication history: adjacent value

Once you are connected to the network, you have access to more than the prescribing transactions. Two adjacent capabilities are worth designing for early because they improve the clinical product meaningfully.

Eligibility and formulary let a prescriber see, at the point of writing, whether a medication is covered by the patient's benefit and what the formulary alternatives are. This is the data that powers "this drug needs prior authorization" or "a covered generic exists" prompts in the prescribing workflow. Surfacing it before the prescription is sent prevents the pharmacy-side RxChange round trips that otherwise create friction for everyone.

Medication history aggregates a patient's filled-prescription history across the network, drawn from pharmacies and payers. For medication reconciliation, safety checking, and getting a real picture of what a patient is actually taking, this is some of the highest-value data on the network - and it is a query, not a prescribing event, so it carries a different and often lighter integration profile than EPCS.

Designing for these from the start, rather than bolting them on later, is what turns a basic e-prescribing feature into a prescribing experience clinicians actually prefer.

A realistic build plan

Putting it together, a Surescripts integration decomposes into a few parallel tracks rather than one monolithic "API project." There is the standards track: model and validate your NCPDP SCRIPT transactions - NewRx first, then the renewal, change, cancel, and fill round trips - against the current required version. There is the certification track: choose direct-versus-intermediary, plan conformance testing, and treat certification and contracting as the schedule-defining workstream. And if controlled substances are in scope, there is the EPCS track: identity proofing, two-factor signing, and third-party audit, started early because it touches your security architecture.

The mistake we see most often is collapsing these into one estimate and anchoring it on the coding. The coding is the predictable part. The certification, the contracting, and the EPCS controls are what determine whether you ship in one quarter or three.

Healthcare is the only industry we work in, and we are FHIR R4 native, which matters here because most modern products need to bridge NCPDP SCRIPT on the pharmacy side with FHIR on the clinical side. We have built EHR and pharmacy integrations for 30+ healthtech startups, and we have open-sourced a Headless EHR covering 28 clinical domains and 70+ FHIR R4 resources, so the prescribing-to-pharmacy path is one we work in routinely. We are HIPAA-compliant, SOC 2, and ISO 27001 certified, which is the security baseline EPCS work assumes you already meet.

Key takeaways

• Surescripts is a national network you connect through, not an API you call - you become a certified participant or ride a certified intermediary.
• E-prescribing is the full NCPDP SCRIPT transaction set (NewRx, RxRenewal, RxChange, CancelRx, RxFill, medication history), not just NewRx.
• Build to the current required SCRIPT version (the 2017071 era replaced 10.6; confirm the version at the start of every project).
• EPCS - identity proofing, two-factor signing, and third-party certification under DEA 21 CFR Part 1311 - is the hardest part. Plan it first if controlled substances are in scope.
• Certification and contracting, not coding, drive the timeline. Budget months, and give certification its own owner.

If you are scoping an e-prescribing build and want a second opinion on the direct-versus-intermediary path, the EPCS workstream, or a realistic certification timeline for your specific use case, book a 15-minute call - we will tell you which path fits and roughly what to expect on the schedule.