FHIR R4 for Medication Data: A 2026 Implementation Guide for Pharmacists and Developers

FHIR R4 is the release to build on for medication data in 2026. It is the first FHIR version with normative content, it is the version named in US certification criteria and in most EU and Swiss exchanges, and three resources carry the clinical payload: MedicationRequest for prescribing, MedicationDispense for dispensing, and MedicationStatement for what the patient reports taking. R5 and the R6 draft exist; nothing in production requires them yet.

The gap is visible in the version numbers. The HL7 continuous-integration build is now labelled v6.0.0-snapshot1 on the FHIR Medication page, while the Java reference implementation still ships R4 structures at 8.13.13-SNAPSHOT in the HAPI FHIR Medication class reference. Drafts move; deployments do not.

Key takeaways

• R4 is normative and stable. Treat R5/R6 as a migration question, not a 2026 build question.
• Coding is the hard part, not transport. FHIR carries codes; it does not carry drug knowledge.
• Use medicationCodeableConcept for the common case and the Medication resource only when you need batch, form or ingredient detail.
• The US, the EU and Switzerland each pin medication exchange to R4, but on different timelines and different code systems.
• Reconciliation problems are usually a status-semantics problem, not a data-volume problem.

What is FHIR R4 and why is it critical for medication data in 2026?

FHIR R4 is the fourth major release of HL7's Fast Healthcare Interoperability Resources, and the first with normative content — the parts unlikely to change. For medication data it defines how a prescription, a dispense and a patient-reported medication move between systems as JSON or XML over a REST API. In 2026 it is still the version regulators and vendors deploy.

The practical consequence: a pharmacist's software and a hospital's EHR can agree on the shape of a prescription without agreeing on anything else. That is genuinely useful and genuinely limited. FHIR standardises the envelope. It does not tell you that two products contain the same active ingredient, that one is reimbursable in Switzerland and not in Germany, or that a dose is unusual. Those answers come from a drug catalogue, and you have to bring one.

Which FHIR R4 resources carry medication data?

Four resources matter. MedicationRequest records a prescription or a proposal to prescribe, MedicationDispense records what a pharmacy actually handed over, MedicationStatement records what a patient says they take, and Medication describes the product itself. Most integrations need the first three and reference the fourth.

What is the FHIR R4 MedicationRequest resource for?

MedicationRequest is the prescribing resource. It carries intent — proposal, plan or order — which is the field teams most often get wrong, because a plan and an order look identical until something is dispensed. It also carries dosageInstruction as free text or structured timing, and dispenseRequest for quantity and repeats.

Query it as MedicationRequest?patient=…&status=active&intent=order, and use _include=MedicationRequest:medication when the request points at a Medication resource rather than an inline code.

What is the FHIR R4 MedicationDispense resource for?

MedicationDispense records the pharmacy event: what was supplied, when, by whom, and how much. It is the resource that closes the loop between a prescription and reality, and it is the one most often missing from an integration, because pharmacy systems were built to talk to claims switches rather than to clinical APIs. whenHandedOver and daysSupply are the fields worth insisting on.

What is the FHIR R4 MedicationStatement resource for?

MedicationStatement is the patient's own account — including over-the-counter products, supplements and anything prescribed elsewhere. It is sparsely populated in most systems and disproportionately valuable in reconciliation, because it is the only resource that can contradict the other two. informationSource tells you whether the statement came from the patient, a carer or a clinician.

How do you integrate FHIR R4 with pharmacy systems?

Start with the identifier, not the resource. Decide how you map your local article number to an external code — Pharmacode and ATC in Switzerland, RxNorm in the US, a national code plus ATC in most of the EU — then build the resource around it. Teams that start with the JSON schema and map codes later spend months on the mapping anyway.

A workable order:

1. Pick the code system per market and record the version. ATC is updated annually; RxNorm more often. Store the code and the version, not just the code.
2. Decide medication[x] shape. Inline medicationCodeableConcept is simpler and covers most reads. Use a reference to a Medication resource when you need batch, form or ingredient.
3. Implement the three reads first — patient's requests, dispenses, statements — before any write. Reads expose your mapping errors cheaply.
4. Handle status honestly. Do not collapse completed, stopped and cancelled into "not active". The distinction is the clinical content.
5. Version your terminology server alongside your API. A code that resolved last quarter may not resolve today.

A minimal request looks like this:

{
 "resourceType": "MedicationRequest",
 "status": "active",
 "intent": "order",
 "medicationCodeableConcept": {
 "coding": [{ "system": "", "code": "…" }]
 },
 "subject": { "reference": "Patient/123" },
 "dosageInstruction": [{ "text": "as directed" }]
}

That is the whole shape. Everything difficult lives in the coding array.

FHIR R4 compliance in 2026: what changes between the US, the EU and Switzerland?

All three pin exchange to R4, but they pin different things and on different clocks. The US regulates certified software and payer APIs. The EU is building cross-border access to prescriptions and patient summaries. Switzerland works from its reimbursement catalogue outward, which is why Pharmacode and the Spezialitätenliste matter more there than any FHIR profile.

The USCDI Medications data class is the reference point for what US systems must be able to exchange; the USCDI Medications data class page is the official list, and it is worth reading before you design a profile.

What are the biggest FHIR R4 implementation challenges in 2026?

The transport layer is solved; the terminology layer is not. The recurring failures I see are coding gaps, status semantics, and the assumption that FHIR includes drug knowledge. It does not. A MedicationRequest with an ATC code tells you the therapeutic class, not the product, the strength or the interaction profile.

• Local codes with no external mapping. Every market has articles that never got an ATC or national code. Decide now whether you reject them or carry them with a local system URI.
• Dose representation. R4's dosageInstruction is looser than people expect. Free text is common and legitimate; do not parse it as if it were structured.
• Status drift. intent and status mean specific things. Mapping them to a boolean loses the reason a medication stopped.
• Terminology versioning. ATC changes yearly. If you do not version codes, your historical records quietly become wrong.
• Interaction checking. This is not a FHIR feature. It needs coded ingredients and a separate knowledge source — the trade-offs are covered in the evolving landscape of drug interaction APIs in 2026.

Medication reconciliation with FHIR R4: what actually works?

Reconciliation works when you compare three resources rather than trusting one. The prescriber's MedicationRequest says what was intended, MedicationDispense says what was collected, MedicationStatement says what the patient believes they take. The gaps between those three are the clinical signal, and FHIR R4 gives you the fields to compute them.

In practice, the dispense-to-statement gap is the most informative and the least populated. If a patient's statement includes a product with no matching dispense in the last ninety days, that is worth a conversation. If a request is active with no dispense and no statement, it is usually an abandoned prescription rather than an adherence problem — but only the status history tells you which.

None of this is clinical advice. It is a data-shape observation: reconciliation fails when teams merge the three resources into one list too early.

FHIR R4 vs R5 vs R6: which version should you build on?

Build on R4 in 2026. R5 was published in 2023 and removed MedicationKnowledge, moving product definition into a separate medication definition specification; R6 is still a draft, currently the v6.0.0-snapshot1 CI build. Neither is what regulators or vendors are asking you to implement. Migrating early buys you nothing and costs you a rewrite.

The honest exception: if you are building a medicinal product registry rather than a clinical exchange, the R5-era product definition work is closer to what you need than R4's Medication resource. That is a different project with a different audience. For prescribing, dispensing and reconciliation, R4 is the answer, and it will be for a while.

Where does coded drug information come from in FHIR R4?

FHIR R4 carries codes; it does not supply them. That is the sentence to remember. A conformant MedicationRequest with an empty or local-only coding array validates perfectly and is useless for interaction checking, reimbursement queries or cross-border exchange. The knowledge — active ingredients, ATC classes, Pharmacode, reimbursement status, interaction pairs — has to come from a catalogue you can query.

That is the part we work on. The Drug Database catalogue is built around the registers rather than around a vendor's internal numbering, so a Pharmacode or an ATC code resolves to the same product record whether you are in a Swiss pharmacy system or a FHIR API. If you want to see whether your mapping problem is already solved, search the catalogue for a product you know and check which identifiers come back.

FAQ

Is FHIR R4 still current in 2026?

Yes. R4 is the normative release that US certification criteria, payer APIs and most EU and Swiss exchanges reference. R5 exists but is not what regulators are asking for, and R6 is still a draft CI build. Plan migrations around R4 for now.

Do I need the Medication resource or just MedicationRequest?

Use medicationCodeableConcept inline for the common case — it is simpler and covers most reads. Reference the Medication resource when you need batch, form, ingredient or manufacturer detail that a single code cannot carry.

Which code system should I use for medication in FHIR R4?

It depends on the market: RxNorm in the US, ATC plus a national code in most of the EU, Pharmacode and ATC in Switzerland. Carry the system URI and the terminology version alongside the code, because ATC is revised annually and unversioned codes age badly.

Can FHIR R4 replace my drug database?

No. FHIR standardises how medication data is exchanged, not what is known about a product. Interactions, reimbursement status, ingredient composition and cross-market identifiers come from a drug catalogue that you query separately and map into the coding array.