Written by Technical Team | Last updated 15.08.2025 | 12 minute read
The Electronic Prescription Service (EPS) is the national backbone for moving prescriptions electronically from prescribers to community dispensers across England. The EPS FHIR API is the modern, RESTful interface to that backbone, allowing software suppliers to create, update, release and dispense electronic prescriptions using HL7 FHIR R4 artefacts. In practical terms, it is how outpatient and secondary-care prescribers can issue prescriptions to community pharmacies without paper, and how pharmacies can securely download and dispense them.
Crucially, the FHIR interface does not just replace messages from older HL7 v3 integrations. It models the whole community prescribing workflow using standard FHIR resources and operations, and introduces patterns that are easier to test and scale. While the EPS core is about getting a valid prescription from A to B, the wider ecosystem now also includes APIs for tracking status for clinicians, surfacing prescription progress to patients, and enabling dispensers to push timely updates when items are ready to collect. Together these form a coherent, Spine-hosted platform for prescribing and dispensing in the NHS.
EPS FHIR is built on HL7 FHIR R4 and uses a mix of FHIR messaging and RESTful operations. The functional model follows four phases: prescribing (creation and digital signing), dispensing (downloading and recording supply events), claiming (reimbursement data to NHSBSA), and management/tracking (status queries and returns). Each phase maps to specific FHIR profiles and operations that you need to design into your product from day one.
At the centre of prescribing is the prescription-order message: a FHIR Bundle of type message whose payload includes MedicationRequest for each prescribed item, Patient, Practitioner/PractitionerRole, Organization, and a Provenance that will hold the prescriber’s digital signature. You send this to EPS using the $process-message operation. Before you do, you call $prepare to canonicalise and digest the order so it can be signed. The API returns a digest, algorithm and timestamp; you then embed the resulting signature in Provenance and submit the signed order to $process-message.
Dispensing hinges on Task and MedicationDispense. Prescriptions are queued on EPS as Tasks. A dispenser downloads them using POST /Task/$release—either all nominated prescriptions for an ODS code or a single prescription using its short-form token. As supply occurs (immediately or over multiple visits), you submit dispense-notification messages via $process-message, with one MedicationDispense per supply event. The EPS model captures partial supplies and “owings” explicitly, so pharmacy systems must update item status and quantities as they go. If nothing has been supplied and the pharmacy cannot dispense, the entire prescription can be returned to EPS by updating Task via HTTP PUT.
Finally, data fidelity depends on standard terminologies and identifiers. Medication coding must use the NHS Dictionary of Medicines and Devices (dm+d), which is aligned with the SNOMED CT UK Drug Extension, ensuring nationally consistent identifiers for every medicinal product. Organisations are identified using ODS codes; you’ll use these to retrieve nominated prescriptions (the $release owner parameter) and to represent the party delivering care across resources. Patient nominations for dispensers are captured as UK-Core-compatible extensions, and your systems should treat them as first-class data.
Key EPS building blocks at a glance:
Security for EPS integrations is a combination of NHS England’s API platform patterns and clinical-grade user identity for signing. For machine-to-machine calls to the EPS FHIR endpoints you’ll use application-restricted access: your application obtains an access token by presenting a signed JWT to NHS England’s OAuth 2.0 authorisation server, and then includes that access token in API calls. This pattern is used for APIs that handle sensitive personal data and is the baseline for production.
For prescription signing, EPS requires a digital signature by an authenticated prescriber. You can integrate a smartcard-enabled local workflow, or—more commonly now—use the Digital Signature Service API, which binds a FHIR prescription to an authenticated CIS2 session for a specific healthcare professional. The $prepare operation transforms your order into canonical signature fragments; you then call the signing API to generate the signature, embed it via FHIR Provenance, and finally send the signed Bundle to EPS.
Onboarding is mandatory and structured. Suppliers submit a use-case form and, if accepted, progress through Tier 3 → Tier 2 → Tier 1 with defined milestones: test in test, test in live, and a monitored first-of-type period with live patients. Completion earns a Clinical Authority to Release (CATR) and full rollout approval. EPS prerequisites—such as integration with directory, identity and terminology services—are assessed via the Supplier Conformance Assessment List (SCAL).
EPS also fits into a wider tracking and patient-experience landscape. Dispensers can publish status updates to the Prescription Status Update FHIR API so patients see progress in the NHS App, and clinicians can query status via the EPS Tracker (moving to a new Clinical Prescription Tracker FHIR API). Design your solution so the prescriber’s workflow, dispenser events, and patient-visible milestones align cleanly.
Security and access checklist:
Think of the full EPS journey as a carefully choreographed exchange between prescriber, EPS (Spine), and dispenser.
It begins in the prescriber system, where you assemble a prescription-order message. For each item, you create a MedicationRequest that uses dm+d coding and structured dose syntax. Build out Patient, Practitioner/PractitionerRole, and Organization entries, ensuring ODS codes and SDS identifiers are present where required. Once you have a complete Bundle, call POST /$prepare, which returns a digest and metadata. Your client then uses the Digital Signature Service (or a compatible smartcard workflow) to have a clinician sign the digest. You embed the signature as a Provenance resource, and submit the now-signed Bundle to POST /$process-message. If an individual item needs to be cancelled after submission (and before dispensing), you send a prescription-order-update to the same $process-message endpoint; EPS will respond with a prescription-order-response when the cancellation is actioned.
Next, the dispenser retrieves the prescription. If the patient has a nominated pharmacy, the system makes a POST /Task/$release call with the pharmacy’s ODS code as owner; EPS marks the returned items as “downloaded” and will not include them in subsequent release calls. Alternatively, a pharmacy can release a specific prescription using the short-form token (group-identifier). Either way, the response is a Bundle containing one or more prescription-order messages and a release reference identifier for use in subsequent dispensing updates.
Dispensing can be a single event or multiple supplies. After each supply event, the dispenser posts a dispense-notification via POST /$process-message, including a MedicationDispense for each item actually supplied. Partial supplies are explicitly supported: set the dispensed quantity and status code accordingly, and repeat with subsequent dispense notifications until the prescribed quantity is fully supplied. “Owings” are represented with a MedicationDispense that omits supply details and carries the appropriate “owing” status. If no items have been supplied and the dispenser cannot fulfil the order, they return the prescription to EPS by PUT /Task, putting the prescription back into a releasable state for another pharmacy to download.
Once an entire prescription is dispensed, the claims phase begins. Endorsements and charge status captured in the dispensing workflow will feed into a Claim message sequence for NHSBSA reimbursement. Although claims are logically separate from EPS’s core exchange of orders and dispense events, you should design your pharmacy system so the “prescribed vs dispensed vs endorsed” data lineage is intact, traceable and audit-friendly. That reduces reconciliation friction and helps ensure accurate reimbursement outcomes.
Finally, tracking and patient updates run alongside the clinical flow. Clinicians can query the status of a prescription using tracker endpoints, and dispensers can proactively push status updates to the national patient experience service so that the NHS App can show patients when items are ready. Baking these signals into your workflow reduces phone calls, improves collection rates, and shortens the loop between prescriber intent and patient therapy.
Design for profiles first, code second. The fastest path through onboarding is to model your resources against the NHS Digital FHIR Medicines Implementation Guide and UK Core from day one. Be strict about MedicationRequest completeness, Provenance shape for signatures, and the message bundle structure for prescription-order, prescription-order-update, dispense-notification and related events. Align your internal object model so that generating and validating these Bundles is routine. Treat Task as your contract with EPS: your local workflow states should mirror Task status and businessStatus transitions, and you should assume EPS is authoritative for whether a prescription is with EPS or with the dispenser.
Make $prepare and signing idempotent and observable. Preparing, signing and submitting is a three-step chain. Network hiccups happen; build idempotency keys into your orchestration so that a retried $prepare or $process-message won’t create logical duplicates. Persist the digest and signature you send, the algorithm used, the prescriber’s identity (from the CIS2 session), and the timestamps. Those fields are your forensic trail for clinical safety cases and SCAL evidence, and they simplify support when a prescriber queries “what exactly did I sign?”
Engineer your release and dispense flows to be resilient. $release is stateful: EPS marks items as “downloaded” once returned, so make sure your dispensing client acknowledges and stores the release reference. If your system crashes after a release but before you persist, you need a recovery story that won’t leak prescriptions or confuse staff. For multi-event supply, keep the MedicationDispense audit trail strictly additive: don’t “edit history”; send new notifications for subsequent supplies and ensure your item status transitions obey the EPS rules for “partial”, “owing” and “not dispensed”. Returning a prescription is a true state transition (PUT /Task) and your UI should confirm no supply has occurred before attempting it.
Treat terminology as a live dependency. dm+d changes continuously. You should build a regular update pipeline for dm+d and the UK Drug Extension so that new products and forms are available, and so older codes that are retired don’t block submissions. On the prescriber side, this minimises free-text fall-backs and helps enforce the structured dose syntax required by NHS England. On the pharmacy side, it ensures MedicationDispense reflects the exact product supplied, which improves downstream analytics and patient medication records.
Plan onboarding like a product launch. The EPS queue and tiered process take time. Start compiling your SCAL evidence early—clinical safety case, hazard logs, security model, data protection impact assessment, and proof of alignment with the FHIR Medicines guide. Engage a partner trust or pharmacy (as needed) at Tier 3 so that by the time you reach test in live, operational staff are ready and you have clinical champions for the first-of-type window. Build a test data strategy that mirrors real-world use: multiple items per prescription, combinations of acute and continuous prescriptions, cancellations, and complex dispensing patterns such as multiple partials and different packs/flavours.
Know the supporting APIs and when to use them. Outside of the core EPS FHIR endpoints, you’ll likely need: the Digital Signature Service for user-attested signatures; Prescription Status Update to push consumer-visible status; and the evolving Clinical Prescription Tracker FHIR API for clinician queries. Each has its own security model and network access expectations; bake these differences into your platform’s API client library and deployment architecture rather than scattering them across the UI.
One widespread source of errors is mismatched identifiers in update calls—for example, attempting to cancel a MedicationRequest with the wrong item ID or out-of-date group-identifier. If EPS responds with an error, treat 4xx responses as unrecoverable without change, and only retry 5xx responses. Build developer tooling that lets you inspect the exact payloads you sent and received, including resource IDs and the MessageHeader for each Bundle. This saves hours during assurance and later in production support.
Another subtle gotcha is status management across partials and owings. Remember that “owing” requires its own MedicationDispense with specific elements omitted (performer, quantity, daysSupply, whenPrepared, dosageInstruction) and the correct status code. When you complete the owing, you record a new dispense event with the actual quantity supplied. Aligning your inventory logic with this messaging pattern prevents reconciliation headaches and ensures that patient-facing updates accurately reflect what happened in the pharmacy.
Lastly, observe the division of concerns: order/authorship on the prescriber side vs. fulfilment on the dispenser side. Avoid building workflows that try to “edit” the original order post-download; instead, cancel at item level where allowed and rely on Task returns if a prescription must be made available to another pharmacy. Keep your audit and observability stacks rich enough to answer “who did what, when, and with what identity and reason?”—that’s not just good engineering, it’s essential to clinical safety and conformance.
Through understanding the EPS FHIR API’s architectural patterns, security model, and message semantics—and by planning your onboarding and operational runbooks with the same care you’d give to a clinical go-live—you can deliver a prescribing and dispensing experience that is safer for clinicians, clearer for patients, and far easier to support at scale. With the right abstractions in your codebase and the right habits in your delivery team, EPS becomes a stable, predictable platform that lets you focus on usability and clinical value rather than wrestling with point-to-point integrations.
Is your team looking for help with EPS integration? Click the button below.
Get in touch