MedicationRequest Handling in FHIR: 5 Patterns for E-Prescribing in 2026

E-prescribing on FHIR looks straightforward on paper — pick a MedicationRequest resource, populate the ingredient, quantity, and prescriber, POST it to your FHIR server. In production, five patterns handle the parts the resource definition leaves ambiguous.

Pattern 1: External MedicationCodeableConcept vs. contained Medication. The MedicationRequest resource supports both a coded reference to an RxNorm/SNOMED concept and a contained Medication resource with detailed ingredient breakdown. The unspoken tradeoff: contained Medication scales badly because every prescription of a compound ends up with a bespoke resource. Systems averaging >1M prescriptions/year should normalize on a canonical Medication resource per RxNorm ingredient set and reference it by URL. The US Core MedicationRequest profile recommends this same pattern for CMS-0057 attestation traffic.

Pattern 2: dispenseRequest.quantity semantics for compound scripts. The quantity element on MedicationRequest.dispenseRequest is ambiguous for compounded prescriptions where the doctor writes "180 g of X" but the pharmacy dispenses "3 × 60 g jars". Two production practices seen: (a) use dispenseRequest.quantity for what the pharmacy will bill and store the prescribed amount in a separate patient-intent extension; (b) generate two dispenseRequests, one authorized, one actual. Pattern (a) has fewer downstream reconciliation problems and aligns with the NCPDP-to-FHIR mapping guidance for compound scripts.

Pattern 3: substitution.allowedBoolean when payer changes formulary mid-fill. NCPDP SCRIPT has a well-understood "brand medically necessary" DAW code that maps to MedicationRequest.substitution. What the spec doesn't cover: what happens when payer flips a brand to formulary-preferred generic between authorization and first fill. In production, EHRs that don't re-check substitution.allowed before dispensing generate 12–15% avoidable pharmacy callback rate. The MedicationRequest R4 specification leaves the timing question open, and pharmacy operations teams generally recommend a re-check at each fill event.

Pattern 4: dosageInstruction as structured data vs. free text. The spec allows either a structured Dosage object or a plain-text text field. Real EHRs still hit text-only in ~40% of prescriptions because the dose complexity (titrate up, PRN, sliding scale) exceeds what the structured Dosage object cleanly represents. Downstream systems that need structured dosage — pharmacy adherence tools, decision-support — should treat text as input and run their own parser rather than assume upstream structuring.

Pattern 5: Sig tapering — the recurring blind spot. FHIR has no first-class way to express "taper prednisone 40 mg × 3 days, then 30 mg × 3 days, etc." The US Core MedicationRequest profile acknowledges this gap and suggests either N discrete MedicationRequests linked by basedOn, or Dosage.sequence with N Dosage elements. The N-MedicationRequests approach fits pharmacy workflows better because dispense events map cleanly; Dosage.sequence keeps the "one script" mental model but forces pharmacy systems to synthesize dispense events.

Vendor support matrix (2026)

The MedicationRequest resource does the job for common prescribing, and the five patterns above cover the recurring rough edges. What still requires implementer decisions is compound dispensing and taper sequencing — neither is a FHIR problem, but the resource shape doesn't solve them automatically.

— Priscilla Hobson