Skip to main content

ADR-0043: Ghasi e-prescribing gateway — Bounded context and FHIR contract

Status: Accepted
Date: 2026-04-04
Decision Makers: Platform Architect, Clinical/Pharmacy Leads
Affected Components: e-prescribing-gateway (Ghasi e-prescribing gateway), fhir-gateway (generic FHIR R4 edge — distinct role), pharmacy, ehr-web (prescribing/chart), Kong routes (/v1/ghasi-e-prescribing-gateway, /fhir/R4), audit pipeline
Canonical overview: GHASI_EPRESCRIBING_GATEWAY.md
Related: GHASI_EPRESCRIBING_GATEWAY.md, specs/modules/ghasi-e-prescribing-gateway/ARCHITECTURE_BASELINE.md, specs/modules/pharmacy/, gan-harness/spec.md

Context​

Ghasi needs a national / enterprise e-prescribing gateway that connects prescriber-side systems (EMRs, EHRs, and other health provider platforms) with pharmacies. The first integration is Ghasi EHR and Ghasi Pharmacy; the same gateway must scale to third-party systems.

The platform exposes a standard FHIR R4 API via fhir-gateway so external partners can integrate with Ghasi EHR clinical domains; that service does not implement national medication routing, subscription SLAs, or gateway-mediated tenancy for prescribe–dispense — it routes FHIR to owning services (see GHASI_EPRESCRIBING_GATEWAY.md §2).

Requirements for the Ghasi e-prescribing gateway: multi-tenant routing, OAuth2/mTLS B2B clients, AuditEvent-aligned logging, store-and-forward for unreliable links, FHIR Subscriptions for status to connected systems, idempotency and version/conflict rules, and alignment with HL7 FHIR, IHE-style audit, WHO-oriented medication safety — without adopting NCPDP SCRIPT or other U.S.-exclusive licensed standards as the mandatory path.

Decision​

  1. Introduce a dedicated e-prescribing bounded context implemented as e-prescribing-gateway (product name: Ghasi e-prescribing gateway) responsible for cross-tenant routing, profile validation at the medication workflow boundary, idempotency and correlation, subscription delivery, and enforcement of who may transition which resource — rather than folding all of that into fhir-gateway. fhir-gateway remains the general FHIR edge; medication resources on /fhir/R4 remain routed per domain ownership (e.g. pharmacy). National e-prescribing traffic uses /v1/ghasi-e-prescribing-gateway and e-prescribing-gateway (GHASI_EPRESCRIBING_GATEWAY.md §2.1).
  2. Standardize the public API contract on FHIR R4 for national IGs and tooling; allow R5 only where a jurisdiction explicitly requires it, with translation at the edge if needed.
  3. Use FHIR Subscription as the normative notification contract; implement the channel as HTTPS with signed payloads, replay protection, and retries (webhook-shaped). Clients must tolerate at-least-once delivery and deduplicate on business/correlation identifiers.
  4. Ownership: Prescriber-side authors and revises MedicationRequest (create/update/cancel per policy). Pharmacy authors MedicationDispense and fulfills; it does not silently overwrite prescriber intent. MedicationRequest.status changes driven by fulfillment are applied only via explicit policy, Task, or prescriber-side action, with Provenance where required. Gateway enforces scopes (e.g. prescriber client cannot write MedicationDispense; pharmacy cannot cancel orders without the allowed workflow).
  5. Concurrency: clients use ETag / If-Match (or equivalent) on writes; gateway returns 412/409 with enough context for clinical products to reconcile or open a Task.

Consequences​

Positive: Clear test surface (contract tests prescriber↔gateway, pharmacy↔gateway); independent scaling of notification and queue workloads; consistent audit and tenancy at the medication hop; aligns with international order vs dispense FHIR patterns.

Negative: Another deployable to operate; duplication risk if validation logic is not shared via libraries — mitigate with shared FHIR validation/IG packages. Persistence: see ADR-0044 (e-prescribing-gateway stores authoritative interop copies; clinical owners remain EHR/Pharmacy products).

Rejected alternatives​

AlternativeWhy rejected
SCRIPT as defaultU.S.-centric licensing and semantics; not the international baseline.
Only extend fhir-gatewayMedication workflow, queues, and subscription SLAs differ from generic FHIR proxy concerns; coupling risks slower releases and unclear ownership.
Ad-hoc webhooks without Subscription modelHarder to align with FHIR auditability and one contract for both first-party apps.