The Pharmacy Data Gap: e-Prescribing, NCPDP SCRIPT, and Why FHIR MedicationRequest Isn't Enough Yet

Every year, more than 22 billion transactions flow through the Surescripts network, connecting over 2 million prescribers to roughly 67,000 pharmacies across the United States. That number represents the vast majority of outpatient prescriptions in the country. If your EHR product touches ambulatory care, you are already downstream of this system, whether you know it or not.

And yet, in the FHIR-centric world of modern health IT, there is a persistent misunderstanding: the assumption that MedicationRequest can replace or subsume the role of NCPDP SCRIPT in e-prescribing. It cannot. These two standards operate at fundamentally different layers. Understanding that distinction, and building your architecture accordingly, is the difference between a system that passes certification and one that actually works in production pharmacy workflows.

This post unpacks the full e-prescribing stack: NCPDP SCRIPT message types, EPCS compliance, FHIR's role (and limitations), the integration architecture that connects them, and the real-world complexity of formulary checking, prior authorization, and medication reconciliation.

The e-Prescribing Landscape: Surescripts and the National Network

Electronic prescribing in the United States is not a fragmented ecosystem. It is a highly centralized one. Surescripts operates the dominant network, routing prescription messages between EHR systems and pharmacy management systems. Their 2024 National Progress Report documents over 22.6 billion transactions processed across e-prescribing, medication history, clinical messaging, and prior authorization.

The network connects:

• 2 million+ prescribers across all 50 states
• 67,000+ pharmacies, including retail chains, independent pharmacies, mail-order, and specialty pharmacies
• Virtually all PBMs (Pharmacy Benefit Managers) for formulary and eligibility data

For an EHR vendor, Surescripts connectivity is not optional. CMS Medicare Part D requirements mandate e-prescribing for eligible providers, and the 21st Century Cures Act has accelerated adoption through its interoperability mandates. If your system generates prescriptions, it routes them through Surescripts using the NCPDP SCRIPT standard.

NCPDP SCRIPT: The Transaction Standard for Prescriptions

The National Council for Prescription Drug Programs (NCPDP) SCRIPT standard defines the message format and semantics for electronic prescription transactions. It is not a clinical data model. It is a transaction protocol — purpose-built for moving prescriptions between prescribers and pharmacies.

Version Landscape: 10.6 vs. 2017071

Two versions dominate production deployments:

• SCRIPT 10.6: The long-standing workhorse. XML-based. Still the most widely deployed version across pharmacies and EHR systems. Surescripts certified systems overwhelmingly use 10.6 for non-controlled substance prescribing.
• SCRIPT 2017071: The current CMS-mandated version for EPCS (Electronic Prescribing of Controlled Substances). Adds digital signature elements, structured SIG (directions), improved medication coding (using RxNorm), and enhanced support for specialty pharmacy workflows. CMS required Medicare Part D prescribers to use 2017071 for EPCS starting January 2021.

The migration from 10.6 to 2017071 has been gradual. Many organizations run dual-version stacks: 2017071 for controlled substances (DEA-mandated) and 10.6 for everything else. Your integration architecture needs to handle both.

Core Message Types

NCPDP SCRIPT defines a family of message types, each representing a specific transaction in the prescription lifecycle:

Each of these messages carries pharmacy-specific data that FHIR resources were never designed to hold: NCPDP pharmacy identifiers, Dispense As Written (DAW) codes, pharmacy notes, structured SIG in NCPDP format, and routing information for the Surescripts network. This is not clinical documentation. This is a financial and operational transaction.

EPCS: DEA Compliance for Controlled Substances

Electronic Prescribing of Controlled Substances introduces a stringent regulatory layer on top of standard e-prescribing. The DEA's Interim Final Rule (21 CFR Parts 1300, 1304, 1306, and 1311) defines specific technical and operational requirements for any application that generates, signs, or transmits prescriptions for Schedule II-V drugs.

The Six Core EPCS Requirements

1. Identity Proofing: The prescriber must complete identity verification through a credential service provider (CSP) that meets NIST SP 800-63 standards. This typically requires government-issued photo ID verification and either in-person or remote proofing.
2. Two-Factor Authentication: Every controlled substance prescription must be signed using two of three authentication factors: something you know (password/PIN), something you have (hardware token, smartphone), or something you are (biometric). Both factors must be presented at the time of signing.
3. Logical Access Control: Role-based access controls must restrict EPCS functionality to DEA-registered practitioners. The system must enforce separation of duties — the person granting EPCS access cannot be the same person using it.
4. Audit Trail: Every prescribing action must be logged with timestamps, user identification, and the specific action taken. Audit records must be tamper-evident and retained for a minimum of two years.
5. Third-Party Audit: The application must undergo an independent audit by a qualified third party before going live and at regular intervals thereafter. The auditor evaluates compliance with all DEA requirements.
6. Digital Signature: Each controlled substance prescription must be digitally signed using a FIPS 140-2 validated cryptographic module. The signature binds the prescriber's identity to the specific prescription content.

For EHR development teams, EPCS adds significant complexity. You are not just sending a message through Surescripts — you are implementing a cryptographic signing ceremony with hardware security requirements, maintaining audit logs that may be subpoenaed, and passing third-party security audits. Many EHR vendors partner with specialized EPCS middleware providers like DrFirst or Imprivata rather than building this in-house.

FHIR MedicationRequest: What It Does Well (and What It Does Not)

FHIR's MedicationRequest resource is a well-designed clinical data model. It excels at representing the intent of a medication order in a structured, interoperable format. If you have worked with FHIR interoperability standards, you know its strengths:

What MedicationRequest Covers Well

• Structured medication coding: References to RxNorm, NDC, SNOMED CT for unambiguous medication identification
• Dosage instructions: Rich Dosage data type with timing, route, method, dose quantity, and max dose per period
• Patient and prescriber references: Clean references to Patient, Practitioner, and Encounter resources
• Intent and status: Lifecycle states (active, completed, cancelled) and intent categories (order, plan, proposal)
• Reason and supporting information: Links to Condition resources that justify the prescription, essential for clinical decision support
• Substitution preferences: Boolean allowed flag and reason code

What MedicationRequest Does Not Cover

• Pharmacy routing: No concept of NCPDP pharmacy ID, Surescripts participant ID, or network routing
• DAW (Dispense As Written) codes: NCPDP defines 9 DAW codes (0-9) with specific legal meanings for brand/generic substitution. FHIR's substitution element is a boolean, not a DAW code
• Structured SIG in pharmacy format: While FHIR has Dosage.text, pharmacies need the SIG in NCPDP-structured format for label printing and DUR (Drug Utilization Review)
• Fill status and dispense notifications: MedicationDispense exists in FHIR but is not part of the e-prescribing transaction flow
• Real-time formulary and drug interaction checking at point of prescribing: This requires integration with Surescripts' Real-Time Prescription Benefit (RTPB) service, not FHIR
• Prior authorization numbers: The PA number assigned by a PBM that must travel with the prescription

This is not a criticism of FHIR. MedicationRequest was designed as a clinical record, not a pharmacy transaction message. Confusing these two roles is where integration architectures break down.

The Integration Architecture: How Both Standards Coexist

In a well-designed EHR integration architecture, FHIR and NCPDP SCRIPT are complementary, not competing. They operate at different layers of the stack:

Layer 1: Clinical Record (FHIR R4)

When a provider creates a medication order in the EHR, the system generates a MedicationRequest resource. This serves as the clinical record of the prescribing intent. It is stored in the FHIR server, made available through the patient's record, accessible via SMART on FHIR apps, and forms the basis of SMART on FHIR integrations. The MedicationRequest becomes part of the patient's longitudinal clinical record.

Layer 2: Transaction (NCPDP SCRIPT via Surescripts)

Simultaneously (or immediately after), the EHR's e-prescribing module translates the order into an NCPDP SCRIPT NewRx message. This message adds pharmacy routing (the specific pharmacy the patient chose), DAW codes, dispense quantity in pharmacy units, and any prior authorization numbers. The message is transmitted to the selected pharmacy through the Surescripts network.

Layer 3: Formulary and Benefit (Da Vinci PDex)

Before the prescription is even finalized, the system may query drug coverage information. The Da Vinci Payer Data Exchange (PDex) Formulary Implementation Guide defines FHIR-based APIs for checking:

• FormularyItem: Whether a drug is on the patient's insurance formulary, its tier, and any restrictions
• InsurancePlan: The patient's specific drug coverage plan, including cost-sharing structures
• Basic (DrugAlternatives): Lower-cost alternatives on formulary

This layer bridges FHIR and the payer ecosystem. It lets the prescriber make an informed drug choice before committing to the NCPDP SCRIPT transaction, reducing downstream rejections and pharmacy callbacks.

The Data Flow in Practice

Provider writes prescription in EHR
    |
    +---> FHIR MedicationRequest (stored in clinical record)
    |
    +---> Da Vinci PDex query (formulary/benefit check)
    |         |
    |         +---> If not on formulary: alert provider, suggest alternatives
    |         +---> If PA required: initiate prior auth workflow
    |
    +---> NCPDP SCRIPT NewRx (transmitted via Surescripts to pharmacy)
              |
              +---> Pharmacy receives, processes, dispenses
              +---> NCPDP SCRIPT RxFill (notification back to prescriber)
              |
              +---> FHIR MedicationDispense (updated in clinical record)

The key insight: the FHIR record and the NCPDP transaction must stay synchronized. When a pharmacy sends an RxChangeRequest (e.g., substituting a generic), the EHR must update both the NCPDP response and the corresponding MedicationRequest in the FHIR server. When an RxFill notification arrives, a MedicationDispense resource should be created. This bidirectional sync is where many implementations accumulate technical debt.

Real-World Challenges That Keep Pharmacy IT Teams Up at Night

Prior Authorization for Specialty Drugs

Specialty drugs now account for over 50% of total US drug spend despite representing only 2% of prescriptions by volume (IQVIA Institute, 2024). Virtually every specialty drug requires prior authorization. The current process is fragmented:

• The EHR initiates a PA request through Surescripts' CompletEPA service or via fax/phone (still common)
• The PBM evaluates clinical criteria, often requiring additional documentation
• Turnaround ranges from hours to weeks depending on the drug and payer
• The NCPDP SCRIPT NewRx cannot be transmitted until the PA number is obtained

The Da Vinci Prior Authorization Support (PAS) Implementation Guide aims to standardize this via FHIR, but adoption remains early. Most production systems still rely on Surescripts CompletEPA or manual workflows. For teams building AI-powered prior authorization solutions, this gap represents both a challenge and an opportunity.

340B Drug Pricing Complexity

The 340B Drug Pricing Program requires covered entities (safety-net hospitals, FQHCs, certain clinics) to track which prescriptions qualify for 340B pricing versus standard pricing. This creates a parallel data flow:

• The NewRx message must be flagged if the patient encounter qualifies for 340B
• Contract pharmacies (external pharmacies dispensing 340B drugs on behalf of covered entities) need additional identifiers in the prescription routing
• Split billing — where some of a patient's prescriptions qualify for 340B and others do not — requires prescription-level tracking that neither FHIR nor NCPDP SCRIPT natively supports well

340B compliance is a significant technical challenge for any EHR serving safety-net providers. The data flows through FHIR (clinical record), NCPDP SCRIPT (pharmacy transaction), and a separate 340B management system, all of which must agree.

Medication Reconciliation Across Care Settings

A patient's "true" medication list is a composite of data from multiple sources, each using different standards and formats. Building accurate medication reconciliation for patient safety requires pulling from:

• Primary care EHR: FHIR MedicationRequest resources (what was prescribed)
• Hospital discharge: FHIR MedicationStatement resources (what the patient was taking at discharge, which may differ from what was prescribed)
• Pharmacy fill data: Surescripts Medication History service, delivered as NCPDP SCRIPT RxFill messages (what was actually dispensed and picked up)
• Patient self-report: OTC medications, supplements, medications from non-connected providers

The gap between "prescribed," "dispensed," and "actually taking" is clinically significant. A patient may have active MedicationRequest resources for drugs they stopped taking months ago. They may be taking medications dispensed at a pharmacy not connected to the EHR. Reconciling these sources is one of the hardest problems in clinical informatics, and it requires fluency in both FHIR and NCPDP data models.

What This Means for EHR Product Teams

If you are building or extending an EHR product that handles prescriptions, here is the practical checklist:

1. Do not try to make FHIR do NCPDP's job. Maintain separate data models for clinical records (FHIR) and pharmacy transactions (NCPDP SCRIPT). Build a synchronization layer between them.
    
2. Plan for dual SCRIPT versions. Support both 10.6 and 2017071. Your Surescripts certification will require it.
    
3. Treat EPCS as a separate workstream. The DEA requirements add cryptographic signing, identity proofing, and audit infrastructure that affect your entire security architecture. Evaluate build-vs-buy carefully.
    
4. Implement Da Vinci PDex early. Real-time formulary checking reduces pharmacy callbacks, improves prescriber satisfaction, and is increasingly expected by payers.
    
5. Design your medication reconciliation pipeline. Pull from FHIR resources, Surescripts Medication History, and patient-reported data. Build conflict detection and resolution workflows.
    
6. Build for the reality that both HL7 v2/FHIR and legacy standards coexist. NCPDP SCRIPT is not going away. FHIR is not replacing it. Your architecture must accommodate both, potentially for the next decade.

Building the Bridge

The pharmacy data gap is not a flaw in either standard. It is an architectural reality. FHIR gives you a modern, RESTful clinical data layer that supports mobile health apps, patient access, and true interoperability. NCPDP SCRIPT gives you a battle-tested transaction protocol that moves prescriptions reliably between 2 million prescribers and 67,000 pharmacies every day.

The teams that build well are the ones that respect this boundary, maintain clean synchronization between both layers, and plan for the regulatory complexity of EPCS, prior authorization, and 340B from the start.

At Nirmitee, we help EHR product teams and healthcare organizations design and implement integration architectures that bridge FHIR clinical records with pharmacy transaction standards. If your team is navigating EHR development and e-prescribing integration, we would welcome the conversation.

Struggling with healthcare data exchange? Our Healthcare Interoperability Solutions practice helps organizations connect clinical systems at scale. We also offer specialized Healthcare Software Product Development services.