Written by Technical Team | Last updated 30.09.2025 | 15 minute read
When medication data crosses organisational and system boundaries, its meaning must remain crystal clear. In England, that clarity is provided by dm+d (the Dictionary of Medicines and Devices), the national medicines standard used to unambiguously identify medicinal products and packs. dm+d is expressed using SNOMED CT identifiers and covers everything from a generic therapeutic moiety through to branded packs with specific strengths and quantities. Because those identifiers are nationally governed and stable across care settings, dm+d has become the lingua franca for electronic prescribing, dispensing and medicines analytics.
The Electronic Prescription Service (EPS) sits alongside dm+d as the operational backbone that moves prescriptions from prescribers to community pharmacies. EPS has historically relied on a mature, safety-hardened messaging approach, with clear business rules around nomination, prescription tokens, claim flows and cancellations. For system integrators, the key is to ensure that the medicinal product you send or receive in any EPS-adjacent workflow is identified by the correct dm+d concept for the level of specificity required. That decision drives everything downstream: whether substitution is allowed, what pack sizes are expected, and how dispensing systems interpret what to supply.
HL7® FHIR® provides the modern interoperability fabric that many NHS APIs now use. While EPS itself has evolved over time, FHIR is increasingly the modelling choice for medication data in and around prescribing journeys—covering medication lists, administration records, discharge summaries, clinical decision support and formulary services. The UK Core profiles constrain international FHIR resources to the national context and, crucially, bind medication concepts to dm+d. When FHIR, EPS rules and dm+d are aligned in your design, you get end-to-end integrity: the code on the prescription matches the pack on the shelf and matches the line item on the reimbursement claim.
It’s worth remembering that dm+d is dynamic. New products, discontinuations, and licensing changes appear in routine updates. Good integrations therefore build for change: they validate that incoming codes are active, handle concept inactivation gracefully, and surface human-readable names alongside codings so that clinicians and pharmacy teams always see what they expect. Put simply, dm+d tells everyone “what”, EPS manages “how” a prescription moves, and FHIR models “how to talk about it” between systems. Bringing those three threads together is the essence of robust medication interoperability.
The starting point for FHIR representations is to choose the right resource for the job. Medication describes the product itself—its code, form, and (optionally) its ingredients—while MedicationRequest expresses a prescription or an instruction to supply that product to a patient. MedicationDispense records what was supplied, MedicationAdministration records what was given to the patient, and MedicationStatement captures a patient-reported or inferred medication usage. For formulary and decision support, MedicationKnowledge can describe legal status, cost, pack characteristics and interactions. Across these resources, the core principle is the same: bind the medicine to a dm+d SNOMED CT code at the appropriate level of granularity.
Within dm+d, different concept classes exist to represent a medicine from abstract molecule to concrete pack. Selecting which one to use is a modelling choice informed by clinical intent and legal requirements. In FHIR terms, that selection drives what goes into Medication.code (and, by reference or containment, what your MedicationRequest.medication[x] points to). A few patterns tend to recur and are worth standardising in your build so that every team member makes the same choice in the same scenario.
Common dm+d concept classes and where they typically land in FHIR include:
A simple rule of thumb helps teams decide: if the prescriber is expressing what medicine and how strong without caring about brand or pack, choose the VMP; if they are specifying an explicit brand, choose the AMP; if they are controlling the pack (for instance for devices, inhalers, or blister-count-sensitive therapies), choose VMPP/AMPP. Whichever you choose, keep human readability front and centre by also populating Medication.code.text with the exact dm+d term string and, in prescription contexts, mirroring it in MedicationRequest.note or MedicationRequest.dosageInstruction.text so the intent is obvious to clinicians and patients alike.
FHIR gives you two primary ways to connect a prescription to a product: by reference (MedicationRequest.medicationReference pointing to a Medication resource) or inline by code (MedicationRequest.medicationCodeableConcept). Referencing a Medication resource is usually preferable for re-use, validation and richer attributes (ingredients, packaging, brand flag, legal category), and it mirrors how dispensary systems think about products. Inline codes can be convenient for simple messages but can make later decision support harder. Whatever you choose, ensure the SNOMED CT system URI and the numeric dm+d identifier are correct and that you carry a stable Medication.identifier for cross-system reconciliation.
Finally, prescribing instructions travel with the product using MedicationRequest.dosageInstruction. Use structured elements wherever possible: doseAndRate for dose amounts, timing for frequency, route for administration route, and additionalInstruction for common phrases like “with food” or “do not crush”. Maintain a full free-text paraphrase in dosageInstruction.text because real-world prescriptions often include nuance that does not fit neatly in codes. This combination of dm+d-coded product and structured, human-readable dose makes prescriptions computable without losing clinical voice.
Real-world prescribing is messy. Titration, paediatric dosing, variable regimens, dose bands and form/device combinations all show up in routine care. A robust FHIR design embraces that messiness with patterns that are safe, repeatable and EPS-aware.
For variable dosing (“one tablet daily for three days, then two daily”), provide multiple dosageInstruction entries ordered with sequence. Each entry can carry its own timing, doseAndRate and text, with a clear narrative that explains the transition. For tapering steroids or up-titrating antihypertensives, this approach keeps each phase explicit and auditable. Where a single instruction truly varies day-to-day (“one or two tablets up to four times daily as required”), use a single dosageInstruction with a range in doseAndRate.dose[x] and a PRN flag via asNeeded[x], paired with a clear text.
Supply and repeat information belongs in MedicationRequest.dispenseRequest. Quantity sits in dispenseRequest.quantity aligned to the product’s unit; duration sits in dispenseRequest.expectedSupplyDuration; and repeat authorisation sits in dispenseRequest.numberOfRepeatsAllowed. For English repeat dispensing (eRD), the repeat count and validity windows must match EPS business rules; model the original issue with a consistent groupIdentifier (the prescription ID) and track subsequent issues with the same grouping so pharmacy systems can reconcile series and claims.
A good FHIR payload is necessary but not sufficient; it must also fit the business and safety expectations of EPS and the UK Core profiles. Start with identifiers. Each prescription needs a stable, globally unique identifier that survives retries and routing—carry that in MedicationRequest.groupIdentifier for items belonging to the same prescription form. At line level, use MedicationRequest.identifier for a unique item ID, and mirror it in dispense and claim messages so the lifecycle of each item is traceable from authoring through dispensing to reimbursement. For cross-system matching, carry ODS codes for organisations and identifiers for prescribers and dispensers in the relevant PractitionerRole and Organization resources referenced by the prescription.
Substitution is both a clinical and legal concept. In FHIR, control it with MedicationRequest.substitution. If a prescription is generic (VMP), it is normally safe to allow equivalent brand substitution; set substitution.allowed[x] to true and, optionally, provide a reason. If a brand is clinically indicated (AMP) and substitution is not allowed, set allowed[x] to false and explain why (e.g., narrow therapeutic index, patient intolerance, device compatibility). This explicit modelling ensures downstream systems and pharmacists honour the prescriber’s intent and that EPS workflows align with the legal status of the product.
Allergies, intolerances and interactions are critical guardrails. Ensure your medication representations can be cross-checked against AllergyIntolerance and problem lists. Because dm+d sits within SNOMED CT, mapping between a VMP code and a recorded allergy to a VTM or specific AMP is computable, enabling software to block unsafe selections while permitting safe alternatives. Carry administration routes and ingredients on the Medication resource where possible, especially for combination products and formulations where excipients matter to particular patients.
UK Core profiles apply national constraints that improve safety and consistency. For example, UK Core medications bind routes and dose forms to national code systems and prescribe cardinalities and must-support flags. Align your validation pipeline to UK Core so that errors are caught before they become operational incidents. Where your use case goes beyond the baseline, adopt UK Core extensions rather than inventing local ones; this keeps your payloads upgradeable and recognisable to counterparties.
Finally, handle edge cases before they handle you. Specials and extemporaneous preparations may exist in dm+d but can lack some of the rich attributes of licensed packs. Devices bundled with medicines—like insulin pens—can blur lines between medicinal product and device. Controlled drugs carry additional legal rules for prescription content and validity. Build explicit branches for these categories, test them with real data, and ensure your UI and service logic make the prescriber’s options clear while keeping FHIR messages coherent and conformant.
The story from authoring to supply is often a relay race with multiple hand-offs. At the authoring stage, your clinical system gathers product, dose, timing, repeats and dispensing information. That data must be internally consistent. If you prescribe a VMP with a 28-day supply at one tablet daily, the quantity should match the intended pack use, or your system should clearly signal that the pharmacist will round to the nearest pack size. When a prescriber selects an AMPP (a specific branded pack), align dispenseRequest.quantity to a whole number of packs rather than loose units, and make the pack size explicit in the Medication resource so downstream systems don’t guess.
Dosage expression is one of the most error-prone aspects of prescribing. For adults on fixed-dose tablets it seems straightforward, but paediatric liquids, cytotoxic regimens and variable warfarin schedules rapidly become complex. FHIR’s Dosage backbone gives you the necessary structure, but a readable paraphrase is just as important. Encourage clinicians to confirm the dosageInstruction.text, and consider generating it automatically from the structured fields with a high-quality natural language template so the free text always mirrors the coded intent. Where titration is planned, use multiple sequences with clear transition cues (“then”, “after seven days”, dates if known) rather than burying instructions in a single paragraph.
Repeat and repeat-dispensing logic must reflect national rules. In repeat dispensing, a batch of issues is authorised up front, with the pharmacy releasing each issue at appropriate intervals until the batch is exhausted or cancelled. In FHIR, carry the repeat count and issue cadence in dispenseRequest, and track each issue with a dispense record pointing back to the original request. When a prescriber changes therapy mid-batch, cancel outstanding issues cleanly and issue a new request with a fresh identifier to avoid ambiguity.
Dispensing systems will use the dm+d code, dose and quantity to determine what to supply. Where a VMP is prescribed, the pharmacy may choose an AMP/AMPP based on stock, reimbursement or patient preference, provided substitution is allowed. Represent that choice in MedicationDispense.medication[x] with the AMP/AMPP code actually supplied, and carry back any clinically relevant differences (device type, delivery mechanism) in note or structured fields so the patient’s record reflects reality. If a prescriber forbids substitution, ensure your validation prevents a VMP choice in the dispense step and instead requires the exact AMP/AMPP.
Operational resilience depends on reconciliation. Prescribing, dispensing and claiming are distinct steps with different systems. Use consistent identifiers end-to-end so you can tie together an authored item, a dispensed line and a claim outcome. Where your platform participates in more than one step, provide reconciliation views for clinical safety and for finance, showing where a prescription line ended up and whether the supplied pack matched the prescriber’s intent. This is particularly valuable when products are discontinued, when dm+d codes are inactivated, or when reimbursement rules change.
Big medication projects fail for small reasons—version mismatches, silent code inactivations, sloppy free text, or one team assuming another will handle edge cases. A disciplined implementation approach keeps the risk manageable and builds trust with clinicians and pharmacy partners. The following blueprint distils the patterns used by successful teams integrating dm+d, medicines standards and EPS-aligned workflows with FHIR.
A few additional practices round out a production-grade build. Separate your authoring model from your exchange model: clinicians work in a rich UI capturing justifications, goals and monitoring plans, while your FHIR payload focuses on the minimum safe set for interoperability. Keep your rendering engine for prescription tokens or patient-facing instructions in lock-step with your Dosage structure so what people read is what the computer believes. And invest in high-quality test data covering everything from simple generics to complex oncology regimens, specials, devices and controlled drugs; if you can’t run them end-to-end in a test environment, you won’t be safe in production.
Finally, don’t neglect analytics. The combination of dm+d and FHIR makes medication data computable at scale: formulary adherence, brand-to-generic switching, dose-range outliers, split pack usage and PRN frequency can all be measured. Feed that learning back into clinical decision support. If analysis shows that a particular variable-dose instruction generates frequent dispense queries, refine your dose templates. If a brand-specific inhaler generates adherence issues due to device complexity, consider setting substitution guidance that steers to a simpler alternative where clinically appropriate.
dm+d provides the single source of truth for medicinal product identity; EPS governs the business of moving prescriptions from prescriber to dispenser; and FHIR, shaped by the UK Core, gives you the modelling vocabulary to express medication intent, supply and outcome in a computable, human-readable way. Choose the right dm+d class for your intent (VMP for generic, AMP for brand, VMPP/AMPP for pack-specific), represent it consistently in Medication and MedicationRequest, and carry structured dose and supply details alongside readable text. Align tightly to national profiles and business rules, automate validation and updates, and treat identifiers as part of your clinical safety equipment, not afterthoughts.
With those principles in place, your integration will do the quiet, vital work that good standards are meant for: a prescriber chooses a medicine and expresses an instruction; a pharmacy dispenses the right product in the right quantity; the patient understands what to take and when; and the data that flows through the system remains coherent, auditable and computable for care, safety and improvement. That is the promise of dm+d, medicines standards and EPS when represented well in FHIR—and it is within reach for any team willing to design for precision, safety and change from the outset.
Is your team looking for help with NHS EPS integration? Click the button below.
Get in touch