Ghasi e-prescribing gateway — canonical overview
Product name: Ghasi e-prescribing gateway
Deployable service (repository): e-prescribing-gateway (apps/services/e-prescribing-gateway)
Kong route prefix: /v1/ghasi-e-prescribing-gateway
Module spec folder: specs/modules/ghasi-e-prescribing-gateway/
Status: Normative product architecture summary (aligns with ADR-0043, ADR-0044)
Last updated: 2026-04-05
1. Purpose and scope
The Ghasi e-prescribing gateway is the platform component that connects prescriber-side systems (EMRs, EHRs, and other health provider platforms) with pharmacies using a national / enterprise interoperability contract: HL7 FHIR R4 medication workflows, durable notifications, tenancy, and audit at the prescription–fulfillment boundary.
First integration (in scope now): Ghasi EHR (prescribing) and Ghasi Pharmacy (dispensing).
Ghasi EHR prescribing vs pharmacy: Interoperable MedicationRequest create/update on the national gateway is owned by orders (CPOE) when clinicians activate medication orders. pharmacy does not submit MedicationRequest on behalf of prescribers; it fulfills by ingesting MR and posting MedicationDispense.
Future: Additional third-party EMRs/EHRs and pharmacy systems attach to the same gateway contract (OAuth2/mTLS B2B clients, scoped personas, idempotent APIs).
The gateway does not replace the clinical medication list, CPOE order lifecycle, or terminology services inside Ghasi EHR; it mediates interoperable copies and workflow state for cross-system prescribing and dispensing per ADR-0044.
2. Relationship to fhir-gateway
| Aspect | fhir-gateway (/fhir/R4) | Ghasi e-prescribing gateway (e-prescribing-gateway, /v1/ghasi-e-prescribing-gateway) |
|---|---|---|
| Primary goal | Single unified FHIR R4 surface for partners integrating with Ghasi clinical domains | Medication interop spine: routing, validation at boundary, subscriptions, idempotency, multi-tenant pharmacy mediation |
| Typical consumers | External integrators, HIEs, apps reading/writing FHIR owned by domain services | Ghasi EHR backend, Ghasi Pharmacy backend, future national connectors |
MedicationRequest / MedicationDispense on /fhir/R4 | Routed per ownership map to pharmacy — read/search projection over local fulfillment rows (queue), not prescriber creation of national interop MR | Not the same path: authoritative national MR/MD live under /v1/ghasi-e-prescribing-gateway FHIR façade and gepgw_ persistence (see §2.1) |
| National MR/MD from first-party backends | /fhir/R4/interop/ghasi-eprescribing/... on fhir-gateway proxies to e-prescribing-gateway (GHASI_EPRESCRIBING_GATEWAY_UPSTREAM_URL). orders uses this path to POST interoperable MedicationRequest (e.g. on medication order activation). pharmacy uses it to GET MR (enrichment) and POST MedicationDispense — it does not POST MedicationRequest as the prescriber. Prefer this path over calling the gateway URL directly from domain services. | Same persistence and behaviour as direct gateway HTTP |
| Subscriptions / outbox / DLQ | Not a responsibility of the generic FHIR gateway | Core responsibility |
| NCPDP SCRIPT | N/A at gateway | Not mandatory; international FHIR baseline per ADR-0043 |
Explicit statement: External partners use the generic FHIR edge (fhir-gateway, Kong /fhir). National e-prescribing semantics are available either via Kong /v1/ghasi-e-prescribing-gateway (direct) or via fhir-gateway /fhir/R4/interop/ghasi-eprescribing/* (proxied). First-party services SHOULD use the interop path on fhir-gateway for centralized policy, auditing, and consistent routing.
2.1 Decision B1 — dual path for medication FHIR (accepted)
Who writes what (Ghasi first-party, national path)
| Resource | Authoritative interop persistence | First-party submitter |
|---|---|---|
MedicationRequest | e-prescribing-gateway (gepgw_*) | orders (CPOE) only — e.g. POST on medication order activation via fhir-gateway /fhir/R4/interop/ghasi-eprescribing/MedicationRequest. pharmacy does not create or “request” prescriptions on behalf of clinicians; it ingests MR from gateway NATS events and optional GET for fulfillment projection. |
MedicationDispense | Same gateway | pharmacy — POST via the same interop path on fhir-gateway. |
Paths
- Generic
/fhir/R4+MedicationRequest/MedicationDispense: Ownership map →pharmacyfor FHIR read/search aligned to local fulfillment projection (partner/clinical read model). This is not whereorderspublishes the national interoperableMedicationRequest. - National interop (authoritative): Persisted by
e-prescribing-gateway. First-party backends SHOULD callfhir-gateway/fhir/R4/interop/ghasi-eprescribing/...(see MEDICATION_EPRESSCRIBING_WORKFLOW_GAP_ANALYSIS.md) rather than the Kong gateway URL directly. - Direct Kong
/v1/ghasi-e-prescribing-gateway: Valid for B2B integrators and tooling that target the gateway product URL explicitly.
Implementations must not assume a single URL for both concerns. Consumer documentation SHALL state which entrypoint applies and which service may POST each resource type on the national path.
3. Relationship to Ghasi EHR platform services
| Service | Role relative to e-prescribing |
|---|---|
terminology | Canonical LOINC, SNOMED CT, RxNorm, ICD-10-CM (and tenant extensions) for search, validation, expansion — medication coding for order entry is rooted here / in EHR UX, not reimplemented in the gateway. |
orders (CPOE) | Only first-party service that submits national interoperable MedicationRequest to the gateway (on medication order activation): fhir-gateway POST /fhir/R4/interop/ghasi-eprescribing/MedicationRequest. Also owns order lifecycle, CDS, events — it is the prescriber-side HTTP client for MR create on the national path; not a duplicate of gateway validation/persistence. |
medication | Longitudinal medication list, reconciliation, MAR / MedicationAdministration — clinical semantics; does not POST national MedicationRequest for the CPOE→pharmacy path. Gateway stores interop FHIR per ADR-0044. |
pharmacy | Fulfillment only on the national path: ingest gateway MedicationRequest notifications (NATS / optional GET), maintain local queue, POST MedicationDispense via fhir-gateway interop path. Does not POST MedicationRequest as prescriber or “request medication” for clinicians. Generic /fhir/R4 routing to pharmacy per ownership map is the read/search projection over fulfillment data — see §2.1. |
| Patient identity | ADR-0042 — authoritative identifiers for cross-system matching; gateway carries references and correlation IDs consistent with platform strategy. |
4. Deployable naming
| Name | Use |
|---|---|
| Ghasi e-prescribing gateway | Product and documentation |
e-prescribing-gateway | Repository folder, Docker/Kubernetes service name, npm package scope |
| Ghasi e-prescribing gateway | Short module label in specs (GHASI-EPGW-EPX) — synonymous with the product in module docs |
| Kong | /v1/ghasi-e-prescribing-gateway → e-prescribing-gateway |
5. Normative contracts
- ADR-0043 — Bounded context, FHIR R4,
SubscriptionHTTPS channel, ownership (prescriber / CPOE →MedicationRequest; pharmacy →MedicationDispense). For Ghasi first-party, MR is submitted byorders; MD bypharmacy. ETag concurrency. - ADR-0044 —
e-prescribing-gatewaystores authoritative interop FHIR for mediated resources; EHR/Pharmacy remain clinical owners. - Module SPEC:
specs/modules/ghasi-e-prescribing-gateway/SPEC.md(FR-RX-*),API_DOCS.md,EVENT_MODEL.md.
6. As-built vs roadmap
Summary aligned to specs/modules/ghasi-e-prescribing-gateway/IMPLEMENTATION_CHECKLIST.md:
| Theme | Shipped / partial | Next (see phased plan) |
|---|---|---|
| Kong, JWT, module entitlement, Postgres, NATS, audit | ✅ | Harden CI, optional Redis |
| FHIR MR/MD CRUD, roles, Zod validation, idempotency (MR POST), ETag, routing, subscriptions, outbox, DLQ, NATS events | ✅ / 🟡 | Full IG validator, $validate, fuzz tests |
| Task, Directory search | 🟡 | FR-RX-020/021 depth, real Organization/Endpoint data |
| P2 (bulk export, CDS, multi-region) | ⬜ | Gated in P2_GATED.md |
7. International alignment (non-normative references)
These inform enterprise gateway expectations; they do not mandate a single national profile:
- HL7 FHIR R4 —
MedicationRequest,MedicationDispense,Subscription, workflow patterns. - IHE — Directory and patient identity patterns where applicable (e.g. mCSD, PMIR) — see national program requirements.
- EU European ePrescription (EESSI) and similar cross-border/national gateway programs — reference models for routing, audit, and dispense reporting (not adopted verbatim).
- WHO medication safety and SMART Guidelines — documented alignment at capability level in module architecture, not a certification claim.
Excluded as mandatory default: NCPDP SCRIPT and other U.S.-exclusive licensed stacks (ADR-0043 rejected alternatives).
8. Related documents
| Document | Role |
|---|---|
IMPLEMENTED_PLATFORM_ARCHITECTURE.md | As-built platform map |
architecture/interop/SOLUTION_DESIGN.md | Interop topology; §3.1.1 medication routing |
specs/modules/ghasi-e-prescribing-gateway/PHASED_IMPLEMENTATION_PLAN.md | Delivery phases |