Draw ePrescribing on a whiteboard, and it usually comes out as three boxes: EHR, network, pharmacy. That picture isn’t wrong, exactly, but it leaves out almost everything an architect has to design. A real ePrescribing system spans a clinical workflow layer that holds the prescriber’s intent, a transaction layer that translates that intent into a defined message format, a network layer that routes and confirms delivery, and a pharmacy and PBM layer that dispenses and checks benefits, all underpinned by a reliability layer that has to track state across every hop.
Identity, signing, and audit requirements for controlled substances cut across several of these layers at once rather than living in one of them. This reference architecture walks through each layer in the order a message moves through it, from the moment a clinician creates an order to the moment a pharmacy confirms a fill, and it’s meant to be the technical foundation the rest of a modernization effort gets built on. A companion piece on the integration challenges EHR vendors run into covers the failure modes that show up when this architecture isn’t mapped out first; this article focuses on what the architecture itself should look like.
A Reference Architecture from Medication Order to Pharmacy
The cleanest way to reason about ePrescribing is as five layers stacked on top of each other, each owning a distinct part of the problem and each capable of failing independently of the others. The clinical workflow layer sits at the top, closest to the prescriber, and holds the medication order as clinical intent. Beneath it, the transaction layer translates that intent into NCPDP SCRIPT messages and tracks their state as they move through the system. The network and directory layer routes those messages to the correct destination and resolves identity questions like which pharmacy a patient meant. The pharmacy, PBM, and payer layer handles dispensing along with an expanding set of real-time services: benefit checks, prior authorization, and formulary lookups that increasingly happen before a prescription is even finalized. And running underneath all of it is a reliability layer responsible for retries, idempotency, and observability, since none of the layers above can tolerate silently losing a message.
Treating these as one undifferentiated “integration” is what leads teams to design a single monolithic handler that tries to do transaction parsing, identity matching, and retry logic all in one place. Separating them early, even conceptually, makes each piece easier to test, easier to replace, and much easier to explain to a new engineer joining the project.
Clinical Workflow Layer: EHR, Medication Order and FHIR
Inside the EHR, a medication order starts as clinical intent: a clinician selects a drug, a dose, a route, a frequency, and a pharmacy, often informed by decision support that checks for interactions or duplicate therapy. HL7’s MedicationRequest resource represents exactly this: a structured, standards-based way to capture a medication order within the broader FHIR clinical data model, independent of how that order eventually gets transmitted to a pharmacy.
This distinction matters more than it might first appear. The clinical workflow layer’s job is to represent what the prescriber intended and to keep that representation stable even while the transaction underneath it changes state repeatedly. If a pharmacy sends back a change request, the clinical order needs to reflect that a change is pending without losing the original intent, and if the change is accepted, the order needs to update without breaking the audit trail back to what was originally prescribed. Systems that conflate the clinical order with the outbound transaction message tend to lose this distinction, which shows up later as confusing prescription histories where it’s unclear what a clinician asked for versus what eventually got dispensed.
Transaction Layer: What NCPDP SCRIPT Does
Below the clinical layer sits the piece that talks to the outside world. NCPDP has named SCRIPT as the standard governing the prescription-related transactions that move between prescribers, networks, and pharmacies, and CMS has adopted SCRIPT v2023011 as the version that will become mandatory for Part D e-prescribing on January 1, 2028. A deeper look at NCPDP SCRIPT and EPCS covers the standard itself in more detail; here, the relevant point is architectural.
The transaction layer’s real job is translation and state tracking, not just message formatting. It takes the clinical order from the layer above and produces a NewRx message, then has to correctly interpret whatever comes back: an acknowledgment, a change request, a fill status update, or a cancellation, each of which needs to be matched back to the original transaction. This is also where version awareness belongs. Since NCPDP SCRIPT versions change on a predictable cadence and the current migration to v2023011 has a hard deadline, the transaction layer should isolate version-specific parsing logic so that a version upgrade touches one well-defined component instead of rippling through the whole system.
Network and Directory Layer: Routing, Connectivity and Service Levels
Once a transaction leaves the integration layer, it needs to reach the right destination, and that’s the job of the network layer. Surescripts describes e-prescribing as a set of distinct transaction types moving across its network, and DrFirst offers an alternative path to similar pharmacy and prescriber connectivity, so an architecture that only assumes one network path is making an assumption worth questioning early. This layer resolves pharmacy identity from a directory, handles routing when a pharmacy has moved or merged, and returns delivery confirmations that the transaction layer has to interpret correctly.
Service-level expectations belong here too. A network can be down, slow, or partially degraded, and the architecture needs a defined behavior for each of those states rather than treating the network as a black box that either works or doesn’t. Teams that skip this design step usually find out about it during a real network outage, when there’s no existing playbook for what the EHR should show a clinician who’s trying to prescribe while the network is degraded.
Pharmacy and PBM Layer: Dispensing, Benefits, RTPB and ePA
At the far end of the transaction sits the pharmacy itself, along with an increasingly active set of PBM and payer services sitting alongside it. Surescripts’ real-time prescription benefit product delivers patient-specific cost and coverage information into the prescribing workflow, often including lower-cost alternatives and prior-authorization flags, and a comparable pattern holds for electronic prior authorization, where a payer’s requirements get surfaced as structured questions inside the same workflow rather than through a separate portal.
The architectural implication is that this layer isn’t just “the pharmacy system a prescription lands at.” It’s a set of real-time services that need to plug into the prescribing workflow before the order is even finalized, which means the clinical workflow layer above has to accommodate a state where the clinician is waiting on a benefit response, a formulary check, or a prior-authorization requirement mid-order. Designing the order screen without that state in mind is one of the more common sources of rework once a team tries to add RTPB or ePA after the fact.
Medication History and Reconciliation Data Flows
A related but distinct data flow runs in the other direction: medication history coming into the EHR rather than a prescription going out. Surescripts’ medication history product is explicitly positioned for reconciliation, pulling together prescribed, dispensed, and sometimes patient-reported medication information from multiple sources rather than presenting a single verified list. NLM’s RxNorm plays a supporting role here as a normalized naming system that can mediate between the different drug vocabularies used by different source systems.
Architecturally, this means medication history needs its own matching, normalization, and provenance-tracking logic, separate from the outbound prescribing path. An incoming medication history record is not automatically a clinically verified active medication, and an architecture that treats it as one, without preserving where the data came from or reconciling it against what the EHR already has on file, creates exactly the kind of data-quality problem a reconciliation workflow is supposed to prevent.
| Working through how these layers should connect in your own system? An architecture review can map the clinical, transaction, network, and security boundaries before implementation locks them in. The Product Engineering team here works with EHR and HIT vendors on exactly this kind of interoperability design, and the Healthcare Interoperability practice focuses specifically on these cross-system data flows. |
Working through how these layers should connect in your own system?
An architecture review can map the clinical, transaction, network, and security boundaries before implementation locks them in. The Product Engineering team here works with EHR and HIT vendors on exactly this kind of interoperability design, and the Healthcare Interoperability practice focuses specifically on these cross-system data flows.
EPCS, Identity, Audit, Security and Compliance
Controlled substance prescribing runs through the same layers described above, but with additional requirements layered on at nearly every step. The DEA’s EPCS requirements call for identity proofing, two-factor authentication at the point of signing, and detailed audit logging for any application used to prescribe controlled substances electronically, and a broader look at security measures for ePrescribing systems covers how that fits into the system’s overall security posture.
From an architecture standpoint, EPCS isn’t a feature bolted onto the transaction layer. It touches the clinical workflow layer, which needs to distinguish controlled substance orders and route them through the appropriate signing flow; the transaction layer, which needs to carry the additional data EPCS transactions require; and the reliability layer, which needs audit logging detailed enough to satisfy a compliance review. Treating EPCS as a separate, self-contained module rather than a set of cross-cutting requirements is one of the more common architectural mistakes in this space, and it’s usually discovered only when a clinician tries to prescribe a controlled substance and the existing workflow has no path for it.
Reliability Layer: State, Retries, Idempotency and Observability
Every layer described so far depends on messages arriving, arriving once, and being traceable when something goes wrong. That’s the job of the reliability layer, which sits underneath the others rather than beside them. A transaction state store needs to track where every prescription is in its lifecycle, from sent through acknowledged through whatever follow-on messages arrive later. Idempotency keys need to prevent a resent message, whether from a network retry or a pharmacy system that timed out and tried again, from silently creating a duplicate order. And observability needs to make it possible to look up any transaction’s current state and history without digging through raw logs, since a support team investigating a “missing prescription” report needs answers in minutes, not hours.
This layer is also where a system’s behavior during degraded conditions gets defined. What happens when a benefit check doesn’t return in time? What happens when the network is unreachable for ten minutes? What happens when a duplicate NewRx arrives for a prescription that’s already been filled? None of these are edge cases in a mature ePrescribing system; they’re routine events that a well-designed reliability layer needs to handle without escalating to a human every time.
FHIR Does Not Replace NCPDP SCRIPT: Choose the Right Boundary
A common architectural misconception is worth addressing directly: FHIR does not replace NCPDP SCRIPT, and treating them as competing standards for the same job leads to the wrong design decisions. HL7’s MedicationRequest resource represents a medication order within the clinical information model, which is exactly the concern of the clinical workflow layer described earlier. NCPDP SCRIPT, by contrast, governs the actual exchange of prescription-related transactions between prescribers, networks, and pharmacies, which is the concern of the transaction layer.
These are different layers solving different problems, and a well-designed architecture uses each one where it belongs rather than trying to make one do the other’s job. A system that tries to use FHIR resources directly as the wire format for pharmacy communication, instead of translating from FHIR-based clinical data into NCPDP SCRIPT at the transaction layer boundary, is working against the grain of how the industry’s standards and pharmacy trading partners operate today.
Architecture Checklist for EHR Vendors
| Layer | Design question to answer before building |
| Clinical workflow | Does the medication order model support a pending-change state without losing original clinical intent? |
| Clinical workflow | Is FHIR MedicationRequest used for clinical representation rather than as a pharmacy wire format? |
| Transaction | Is version-specific NCPDP SCRIPT parsing isolated into its own component? |
| Transaction | Does the transaction layer track state across every follow-on message type? |
| Network | Does the architecture assume a single network path, or does it accommodate multiple connectivity options? |
| Network | Is there a defined behavior for degraded or unavailable network conditions? |
| Pharmacy/PBM | Can the order workflow accommodate a pending RTPB or ePA response mid-order? |
| Medication history | Is provenance preserved separately for prescribed, dispensed, and patient-reported data? |
| EPCS/security | Is identity proofing, signing, and audit logging designed as cross-cutting requirements, not a bolt-on module? |
| Reliability | Are idempotency keys implemented to prevent duplicate orders from retried or resent messages? |
| Reliability | Can any transaction’s current state and history be looked up without reading raw logs? |
Conclusion: Design the Layers Before You Design the Interfaces
Every area covered in this architecture (clinical workflow, transaction, network, pharmacy and PBM, medication history, EPCS, and reliability) fails in its own way, and the teams that get the fewest surprises in production are the ones who map all of them before writing integration code rather than discovering them one at a time. Treating ePrescribing as a single “connect to a network” task, instead of a layered system with its own state, identity, and compliance boundaries, is what turns a straightforward-looking project into a multi-quarter rework.
This architecture is also the foundation the rest of this series builds on: how real-time prescription benefit fits into the pharmacy and PBM layer, how medication history reconciliation works as its own inbound data flow, and how electronic prior authorization plugs into the same workflow boundary as RTPB. Mapping these layers clearly now is what makes each of those more specialized integrations easier to design later, rather than harder. The Product Engineering and Healthcare Interoperability teams here work with EHR and HIT vendors on exactly this kind of layered architecture review, before development or a modernization effort locks in a design that’s difficult to unwind.
Frequently Asked Questions
Does FHIR replace NCPDP SCRIPT in ePrescribing?
No. FHIR’s MedicationRequest resource represents the clinical medication order, while NCPDP SCRIPT governs the actual prescription transactions exchanged between prescribers, networks, and pharmacies. They operate at different layers of the architecture and are not interchangeable.
Where does RTPB fit into the architecture?
Real-time prescription benefit sits in the pharmacy and PBM layer, but it needs to surface inside the clinical workflow layer before a prescription is finalized, which means the order screen has to support a pending-benefit-response state rather than treating the order as complete once the clinician clicks send.
Why does medication history need separate architecture from outbound prescribing?
Medication history is an inbound data flow with its own matching, normalization, and provenance requirements, since the data can come from multiple sources of varying reliability. Treating it as the same pipeline as outbound prescription transactions tends to lose the source-tracking information a reconciliation workflow depends on.
Is EPCS a separate system from standard ePrescribing?
No, EPCS runs through the same architectural layers as standard ePrescribing, with additional identity, signing, and audit requirements layered across the clinical, transaction, and reliability layers rather than isolated in one module.
Latest posts by Priti Prabha (see all)
- The Architecture Behind Modern ePrescribing Systems - September 8, 2026