e-Prescribing and EPCS

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If your telemedicine product treats anything — mental health, primary care, urgent care, addiction medicine — a clinician will eventually want to prescribe, and patients expect the prescription to land at their pharmacy before the call ends. Getting there means wiring into a national network, meeting drug-database safety expectations, and, for controlled substances, satisfying a Drug Enforcement Administration (DEA) rulebook that governs how a prescriber proves who they are and signs the order. This is a build-versus-buy decision with real compliance exposure: a mistake here is not a bug, it is a federal violation. This article is for the founder, product manager, or compliance lead who needs to scope e-prescribing honestly, talk to vendors and auditors, and avoid promising a feature the regulations will not let you ship on your timeline.

What "e-prescribing" actually means

A paper prescription is an instruction from a prescriber to a pharmacist. Electronic prescribing, usually shortened to e-prescribing or eRx, is the same instruction sent as a structured electronic message instead of ink on a pad. The clinician picks the drug, dose, and pharmacy inside your app; your app turns that into a standardized message; the message travels over a network to the pharmacy's software; and the pharmacy fills it. The patient often arrives to find the prescription already waiting.

Two pieces of plumbing make this work, and you should know both names.

The first is the message format, called NCPDP SCRIPT. NCPDP stands for the National Council for Prescription Drug Programs, the standards body that defines how a prescription is written in machine-readable form. SCRIPT is its prescribing standard, and it covers more than the first prescription: a new prescription (NewRx), a refill request and response (RxRenewal), a change request when the pharmacy needs a different dose or drug (RxChange), and a cancellation (CancelRx). Medicare's Part D drug program requires a specific version of this standard — NCPDP SCRIPT 2017071 is the floor for 2026 — and the industry is moving to the newer 2023011 version, so any integration you build must let you upgrade the SCRIPT version without a rewrite.¹²

The second piece is the network that carries those messages: Surescripts. Surescripts is a national health-information network that routes e-prescriptions between essentially every prescriber and pharmacy in the country; it processed more than 30 billion transactions in 2025.³ One point trips up almost every team new to this space, so state it plainly: Surescripts is a network operator, not an API you sign up for. There is no public developer portal where you grab an API key. You reach the network either by going through a certification process to connect directly, or — far more commonly — through an e-prescribing vendor that has already done that work and exposes a clean API to you.

Figure 1. The e-prescription data flow. Your app builds an NCPDP SCRIPT message; an e-prescribing module routes it over the Surescripts network to the patient's pharmacy. Every hop that carries patient data needs a Business Associate Agreement.

Around the core "send a prescription" path sit three supporting services your clinicians will expect. Medication history pulls the patient's recent fills so the prescriber sees what they are already taking. Drug-interaction and allergy checking — software that warns when two drugs clash or a drug conflicts with a recorded allergy — is clinical decision support, usually licensed from a drug-knowledge vendor such as First Databank or Medi-Span rather than built in-house. And benefit and formulary checks — increasingly the Real-Time Prescription Benefit (RTPB) service — tell the prescriber, while they are still choosing the drug, whether the patient's insurance covers it and what it will cost. None of these are legally mandatory to send a prescription, but a product without interaction checking is a patient-safety problem, not a lean MVP.

Why prescribing is PHI before it is anything else

A prescription names a patient and a drug, which together reveal a health condition. That makes the whole e-prescribing flow Protected Health Information (PHI) — any health data tied to an identifiable person — and it pulls in the HIPAA rules that govern the rest of your telemedicine platform.

The practical consequence is the Business Associate Agreement (BAA) — the signed contract that lets an outside vendor handle patient data on your behalf, and the same instrument you needed for your video and storage vendors. Your e-prescribing vendor handles PHI, so you need a BAA with them; Surescripts sits in the path, so its participation must be covered too. "The data is encrypted" does not substitute for this. Encryption protects the message in transit; the BAA is the legal permission to send it at all. A vendor either has a signed BAA covering your use or it does not, and for a prescribing pipeline the answer must be yes before a single live prescription moves.

If you have not yet mapped which of your vendors are business associates, our explainer on the Business Associate Agreement is the place to start, and the broader HIPAA guide for telemedicine product teams sets the frame the rest of this article builds on.

The line that changes everything: controlled substances

For an ordinary medication — a blood-pressure pill, an antibiotic, an inhaler — the flow above is the whole story. Build or buy the integration, sign your BAAs, send the message.

The rules change the instant the drug is a controlled substance: a medication the DEA places on a schedule because it carries a risk of misuse or dependence. These run from Schedule II (high abuse potential — most opioids, stimulants like those used for ADHD) down through Schedule V (lower risk). Prescribing these electronically is governed by a dedicated DEA rule set known as EPCS — Electronic Prescriptions for Controlled Substances — codified in federal regulation at 21 CFR Part 1311.⁴

EPCS exists because a controlled-substance prescription is a target for fraud and diversion. The DEA's answer is to make the system prove, to a high bar, that the real prescriber — and only the real prescriber — authorized this exact order. Three layers of regulation now stack on the same prescription, and seeing them as a stack is the single most useful mental model for scoping this feature.

Figure 2. Three regimes stack on one controlled-substance prescription: HIPAA governs the patient data, DEA EPCS governs how the order is identity-proofed and signed, and the Ryan Haight Act plus state law govern whether this clinician may prescribe to this patient at all.

The EPCS requirements, in plain language

The DEA's EPCS rule reads like a security specification because it is one. Here are the requirements that actually shape your product, each tied to the rule that imposes it.

Identity proofing to a high assurance level. Before a clinician can ever sign a controlled-substance prescription, their real-world identity must be verified — not just "they have a login," but "a trusted party confirmed this is a real, credentialed prescriber." The rule requires identity proofing at Identity Assurance Level 2 (IAL2) of the federal identity standard NIST SP 800-63-3, performed by an approved credential service provider or certification authority.⁵⁶ In a telemedicine context this is usually done remotely, by an identity vendor that checks government ID and credentials over a verified video or document flow. This connects directly to the broader question of how you establish roles, identity, and consent across your platform.

Two-factor authentication on every signing. To sign each controlled-substance prescription, the prescriber must authenticate with two of three factors: something they know (a password), something they are (a biometric such as a fingerprint), and something they have (a separate hardware or phone-based token). The rule is specific that if the "something you have" factor is a hard token, it must be separate from the computer being used and meet at least FIPS 140-2 Security Level 1 — the federal baseline for a cryptographic device.⁷ In product terms: a password alone never signs a controlled substance, and the second factor cannot live on the same screen the prescriber is typing into.

Two people to control access. A single administrator cannot quietly grant themselves controlled-substance signing rights. The rule requires at least two individuals to manage logical access control in the application, and at least one of them must be a DEA-registered prescriber who holds a two-factor credential. One person requests the access; a second, separately, must verify the prescriber's DEA registration and state license are current before the signing capability is switched on.⁸ This is a deliberate separation of duties, the same principle that keeps one bank employee from both creating and approving a wire.

A digital signature the prescriber never has to think about. When the prescriber completes two-factor authentication, the application digitally signs the prescription record and transmits it. The signature binds the order to the prescriber so it cannot be altered in transit without detection.

Third-party certification or audit of the software itself. This is the requirement that most surprises teams. Your e-prescribing application cannot simply assert that it meets the EPCS rules; it must be certified or audited by a qualified independent third party before it processes a single controlled-substance prescription, and again whenever the controlled-substance functionality changes or every two years, whichever comes first.⁹ The DEA recognizes a short list of certifying firms (for example, Drummond Group, iBeta, and similar auditors). This is a recurring cost and a release constraint, not a one-time gate — change the wrong part of the signing flow and you trigger a re-audit.

Figure 3. The five EPCS gates. Every one must be satisfied before a controlled-substance prescription can be signed and sent — and the third-party audit recurs at least every two years.

Common mistake: treating EPCS as a feature flag. Teams plan controlled-substance prescribing as "turn on the controlled-substance option in the vendor SDK." EPCS is not a toggle. It is identity proofing for every prescriber, a separate second factor in their hands, a two-person provisioning process, and a recurring third-party audit of your build. If your roadmap says "add EPCS in a two-week sprint," the roadmap is wrong. The realistic unit is months, and most of that time is process and audit, not code.

The other rulebook: Ryan Haight and the 2026 telemedicine flexibilities

EPCS governs how a controlled-substance prescription is signed. A second federal law governs whether a telemedicine clinician may write one at all.

The Ryan Haight Online Pharmacy Consumer Protection Act generally requires at least one in-person medical evaluation before a practitioner can prescribe a controlled substance over the internet. During the COVID-19 public health emergency the DEA waived that in-person requirement, and it has repeatedly extended the waiver since. As of this writing, the DEA and the Department of Health and Human Services have issued a fourth temporary extension that keeps the telemedicine prescribing flexibilities in place from January 1, 2026 through December 31, 2026 while the agency finalizes permanent rules.¹⁰ Separately, two final rules effective at the end of 2025 created specific, narrower pathways — including a six-month initial buprenorphine supply for opioid-use-disorder treatment via audio-only telemedicine — that carry their own conditions.¹¹

The product implication is blunt: the legal basis for telemedicine controlled-substance prescribing currently rests on a dated, temporary extension. Build the feature, but treat the in-person rule as a configuration that can change, instrument your product to enforce whatever the current pathway requires, and put the December 31, 2026 expiry on your compliance calendar. The deeper map of cross-state licensing and prescribing rules lives in our article on state and specialty rules: licensing and prescribing.

Figure 4. The telemedicine prescribing decision in 2026. A non-controlled drug takes the standard e-prescribing path; a controlled substance must clear both the EPCS signing gates and the Ryan Haight pathway, which currently relies on a temporary extension.

Build versus buy: the math almost everyone runs the same way

You can connect to Surescripts directly, or you can integrate an e-prescribing vendor — DoseSpot, DrFirst, Veradigm, and similar — that has already certified its connection and offers EPCS as a service. Run the numbers and the choice is usually clear.

Consider the direct path. Surescripts certification alone typically runs 8 to 16 weeks of conformance testing against the NCPDP SCRIPT, prescription-benefit, and cancellation transaction sets.³ Controlled substances add the DEA-required third-party EPCS audit before go-live, and that audit recurs at least every two years. So the time-to-first-prescription on the direct path is, roughly:

8–16 weeks (Surescripts certification)
+  6–10 weeks (EPCS third-party audit + remediation)
+  engineering to build and maintain the SCRIPT message layer
= a multi-quarter project, plus a recurring biennial audit you now own

Integrating an established vendor collapses the first two lines: the vendor holds the Surescripts certification and the EPCS audit, and you consume an API. You still sign a BAA, you still handle prescriber identity proofing and two-factor enrollment, and you still pay per-prescriber or per-transaction fees — but you reach a live, compliant prescription in weeks, not quarters. For all but the largest health systems, buying the network connection and owning the clinical experience on top is the rational default.

The table below is the comparison that matters most, and like every vendor table in this section it includes the question that decides whether a vendor can touch PHI at all.

Vendor capabilities and pricing change; confirm the BAA, the current EPCS certification, and the supported NCPDP SCRIPT version directly with each vendor before you commit.

This is the same build-buy logic we walk through for the video layer and for EHR integration via HL7 FHIR — and prescribing sits inside the wider telemedicine integration map alongside scheduling, labs, and billing.

Where Fora Soft fits in

Prescribing is a compliance problem before it is an engineering problem, and we scope it that way. When we build telemedicine platforms, we treat the e-prescribing layer as PHI under HIPAA from the first design session, integrate an EPCS-certified network partner under a signed BAA rather than reinventing the Surescripts connection, and wire prescriber identity proofing and two-factor signing into the same identity system that governs the rest of the product. Our work across telemedicine, video conferencing, and secure real-time video since 2005 means we connect the prescription flow to the consult, the record, and the audit log as one coherent system — so the capability a clinician sees as "send to pharmacy" is, underneath, fully inside the compliance boundary.

What to read next

• The telemedicine integration map
• State and specialty rules: licensing and prescribing
• HL7 FHIR and EHR integration

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your epcs requirements plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the e-Prescribing & EPCS Readiness Checklist — One page to scope the prescribing layer of a telemedicine product: the network (NCPDP SCRIPT over Surescripts), the BAA boundary, the five DEA EPCS gates (IAL2 identity proofing, two-factor signing, two-person access control, digital….

References

Additional source consulted: SUPPORT for Patients and Communities Act §2003, mandating EPCS for Medicare Part D Schedule II–V prescriptions effective Jan 1, 2021 (CMS delayed enforcement to Jan 1, 2022) — Surescripts/CMS summaries, Tier 4/1. https://surescripts.com/news-center/intelligence-in-action/opioids/cms-should-proceed-with-epcs-requirement-without-another-delay — checked 2026-06-14.