Orders Service — Service Overview
Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template
1. Purpose
The orders-service is the Computerised Physician Order Entry (CPOE) hub of the Ghasi eHealth platform. It consolidates all clinical order types — medication, laboratory, radiology, procedure, referral, nursing, diet, and activity — under a single bounded context. It enforces Clinical Decision Support (CDS) checks at order entry, manages order set templates, routes orders to fulfilment services, and tracks order lifecycle through to completion or cancellation.
ADR-0046 note: The standalone requisitions-referrals-service has been retired. All requisition and referral functionality is now consolidated in this service. Existing FR-REQ-* and FR-REF-* requirements are re-numbered as FR-ORDERS-*.
Module license key: clinical.orders
2. Bounded Context
| Aspect | Detail |
|---|---|
| Domain | Clinical — Order Management |
| Context name | Orders / CPOE |
| Aggregate roots | Order, OrderSet |
| FHIR resources owned | ServiceRequest, MedicationRequest, NutritionOrder, Task (order fulfillment tracking) |
| NATS subject (produced) | clinical.orders.{patientId} |
| Database schema | orders |
| Module entitlement | clinical.orders |
3. Responsibilities
| Responsibility | In scope | Out of scope |
|---|---|---|
| CPOE for 8 order types (medication, lab, radiology, procedure, referral, nursing, diet, activity) | Yes | Medication dispensing (pharmacy-service) |
| CDS checks: allergy, drug-drug, duplicate, dosing | Yes | CDS rule authoring (terminology-service) |
| Order set management and instantiation | Yes | Clinical protocol authoring |
| Referral creation and tracking | Yes | Scheduling referred appointment (scheduling-service) |
| Lab/radiology requisition creation | Yes | Result entry (laboratory-service, radiology-service) |
| Order lifecycle management (draft → active → completed/cancelled) | Yes | Fulfilment execution |
| FHIR ServiceRequest/MedicationRequest/NutritionOrder read+search | Yes | FHIR write from external systems (interop-service adapter) |
| Batch orders (order sets instantiation) | Yes | Bulk import of legacy orders (migration script) |
4. Upstream and Downstream Dependencies
5. Key Architectural Decisions
| Decision | Choice | Rationale |
|---|---|---|
| Single service for all order types | Consolidated orders-service (ADR-0046) | Eliminates cross-service saga complexity for order workflows; unified CDS gate |
| CDS as synchronous pre-commit check | CDS guard in-process with remote rule evaluation | Blocking CDS on medication orders is patient-safety requirement |
| FHIR resource mapping | ServiceRequest (lab/radiology/procedure/referral), MedicationRequest (medication), NutritionOrder (diet) | Follows FHIR R4 resource ownership map |
| Order lifecycle state machine | draft → active → on-hold → completed/cancelled/entered-in-error | Matches FHIR ServiceRequest status vocabulary |
| NATS subject per patient | clinical.orders.{patientId} | Enables ordered event delivery per patient for downstream consumers |
| Order sets | Template + instantiation pattern | Reduces ordering time for common clinical protocols |
6. Non-Goals
- This service does not dispense medications (pharmacy-service).
- It does not record results (laboratory-service, radiology-service).
- It does not schedule the referred appointment (scheduling-service picks up
referral.createdevent). - It does not author CDS rules (terminology-service owns the rule set).