Closed-loop medication management on one platform: twelve safety engines that screen every order, a fulfillment lifecycle that cannot skip a step, and a stock ledger the database itself refuses to let anyone rewrite.
Not a status dropdown. Fifteen states with explicitly legal transitions between them, so a dose cannot reach a patient by skipping verification, and an exception cannot be disguised as a completion.
Plus the exception edges every real pharmacy needs: cancelled, returned, waste, recalled, lost and damaged, each with a mandatory reason.
Medication Safety
Screening is automatic. Judgement stays human. The system decides how much scrutiny an order earns, and a pharmacist decides what to do about it.
Allergy and cross-reactivity, drug interactions, dose range, therapeutic duplication, renal and hepatic adjustment, pediatric, geriatric, pregnancy, lactation, high-alert and controlled classification, and pharmacogenomics. Every order is screened before a pharmacist ever sees it.
Level 1 automated for low-risk orders, level 2 pharmacist, level 3 clinical pharmacist when findings accumulate, level 4 dual authorization. The level is derived from the findings, not chosen by whoever is on shift.
A pharmacist can override a warning, but the override is a recorded action with a reason and an actor. Controlled and high-alert findings can be configured to force dual authorization instead.
Per-organization CDS policy sets the finding count that escalates to clinical review, whether automated verification is permitted at all, and which findings become hard stops.
Each finding carries its severity, the rule that produced it and its evidence source, so a reviewing pharmacist sees why the system objected, not just that it did.
When an order needs a question answered rather than a refusal, the pharmacist raises a clarification against it and the fulfillment holds until it is resolved.
Dispensing
The prescription belongs to the prescriber. The fulfillment belongs to the pharmacy. Keeping them distinct is why both stay trustworthy.
Pending, reserved, picking, verification, packaging, label printed, dispensed, collected, closed, plus cancelled, returned, waste, recalled, lost and damaged. A state cannot be edited directly: every move is checked against an explicit state machine.
Return, waste, recall, lost and damaged are modelled states with a mandatory reason, not a status field someone types into. Terminal states stay terminal.
Barcode and GS1 element parsing verify the right product and the right batch at the point of picking, with GTIN, lot and expiry read from the carrier itself.
Labels are generated from the dispense record and reprinting is a governed, separately-permissioned action.
Prescriptions are read live from the Doctor Module over internal federation and are never copied into the pharmacy database. There is one prescribing record, and the pharmacy annotates it rather than forking it.
If the prescribing module is unreachable the response says so explicitly, so the queue renders as unavailable and never as a reassuring, empty 'no prescriptions'.
Inventory
Most pharmacy systems store a quantity and hope. Eruntar stores every movement that produced it, append-only, and the database rejects attempts to change history.
Every movement writes one row with the previous and new balance, the actor, the reason and what it referenced. Database triggers reject UPDATE and DELETE outright, so stock history cannot be quietly rewritten.
Batch number, lot, expiry, manufacture date, supplier and unit cost on every batch, with statuses for available, quarantined, expired, recalled and destroyed.
First-expiry-first-out selection is indexed at the database level and skips quarantined and recalled batches automatically.
A dispense reserves batch quantity first and consumes the reservation only when the medicine actually leaves. On-hand and reserved move in the same transaction as the ledger append.
Pharmacy, zone, cabinet, shelf and bin as a real tree, with stock transfers between locations that carry their own request and approval workflow.
Stock adjustments are requested and approved as separate actions, and every variance reconciles back through the same ledger.
Supply Chain
Purchase request, approval, purchase order, confirmation, goods receipt. Receiving a PO creates the batch and its ledger entry through the same inventory engine, so nothing enters stock by a side door.
Per-drug reorder points and suggested order quantities, with the engine flagging everything at or below its threshold.
Consumption-value classification, clinical-criticality classification with manual override, and movement-frequency analysis: the inventory triage hospital pharmacies actually run on.
Temperature-controlled batches carry their required range, readings are recorded against them, and a logged excursion quarantines the batch automatically rather than waiting for someone to notice.
A background worker moves expired batches out of available stock, and near-expiry and expired counts sit on the dashboard as first-class numbers.
Supplier records with metrics derived from actual purchase-order history, not from a spreadsheet someone maintains separately.
Controlled Substances & Recalls
Controlled-substance custody is where pharmacy software is judged. It is modelled here as an immutable register with witnesses, not as a report generated after the fact.
An immutable chain-of-custody log for schedules II to V: receipt, dispense, return, destruction, adjustment and count, each with a running balance after the movement.
Controlled movements record a second authorizer alongside the performing user, and opening a vault is a separately-permissioned, step-up-gated action.
Reconciliation sessions compare the register's running balance against the physical count, and variances are surfaced as a tracked number rather than absorbed.
Configurable thresholds monitor dispensing patterns for diversion signals, and an investigation is an approval-gated workflow with its own audit trail.
Initiating a recall quarantines every matching batch so FEFO stops selecting them, and identifies the patients who already received the drug.
Regulated actions capture an electronic signature, and signature volume is itself a reported compliance metric.
Clinical Pharmacy
Clinical pharmacy is the part of the job that justifies the department, and it is usually the part that vanishes into free-text notes. Here it is structured data with an outcome.
Twenty workspaces, one module
Medication orders, dispensing, prescriptions, inventory, analytics, replenishment, transfers, procurement, cold chain, controlled substances, recalls, labels, clinical review, interoperability, reports, security, governance, capabilities, AI governance and operations.
Interoperability
HL7 and NCPDP messages are translated the moment they arrive and never reach business logic in their raw form, which is why adding a standard does not destabilise the workflow.
MedicationDispense, Medication, InventoryItem and SupplyRequest served as FHIR R4 resources, with a CapabilityStatement and OperationOutcome errors, so an external system can discover what this pharmacy exposes.
Inbound RDE^O11 pharmacy orders are translated at the edge and never reach business logic as raw HL7.
Inbound NewRx electronic prescriptions are adapted into the same internal order shape as everything else.
GTIN, lot, expiry and serial parsed from GS1 element strings for receiving and dispense verification.
Domain events ride a transactional outbox with retry and backoff, webhook delivery, natural-key idempotency and a classified dead-letter queue you can actually inspect.
A typed capability model for barcode scanners, label and receipt printers, electronic scales, tablet counters, dispensing cabinets, robotic dispensers, RFID readers, smart refrigerators and temperature sensors.
Pharmacy Intelligence
In beta the advisory layer is deliberately deterministic: it composes from the dispense record and the safety findings, and invents nothing. We would rather ship a stub we can defend than a claim we cannot.
Draft counseling points composed from the dispense record and its deterministic safety findings, carrying a disclaimer that they are not patient-ready. A pharmacist must review and personalize before anything reaches a patient.
Plain-language explanation of why a CDS finding fired, generated from the rule and its inputs rather than invented.
The AI layer cannot change a dispense, release an order or move stock. Human-in-the-loop is enforced in code, not promised in a policy document.
Every AI interaction is recorded with its prompt version, tenant policy and outcome, and acceptance rate is a reported metric. Feature flags gate AI by tier.
The AI governance register ships with its safety rules written as executable tests, so a violation fails the build instead of a review meeting.
The advisory layer is deliberately deterministic today and versioned behind a stable prompt registry, so a licensed clinical model slots in without reworking the workflow around it.
Security & Governance
That sentence is from the module's own architecture specification, and the code enforces it: every transition is validated, every regulated action is permissioned, and the sharp edges ask who you are again.
43 granular pharmacy capabilities across 9 categories, each mapped to a stage of the medication lifecycle, published to the admin panel and second-checked at enforcement time.
From chief pharmacist and clinical pharmacist to controlled drug officer, procurement officer, compliance officer and regulatory inspector: least-privilege roles that match how a pharmacy is actually staffed.
22 actions require re-authentication at the moment of use, including dispensing controlled drugs, opening a vault, overriding a CDS warning, emergency dispensing and approving adjustments.
An append-only audit log, tracked security incidents, denial monitoring and field-level encryption for sensitive values.
Every table carries organization and branch, and every query is scoped to both. Entitlement to the pharmacy module is checked before any request reaches a controller.
Published service level objectives, p95 latency histograms, readiness checks and scoped request logs, with 168 automated tests across the domain run in CI.
One Platform
The Pharmacy Module reads the prescriber's active medication orders live from the Doctor Module and never copies them, so there is exactly one place a prescription exists and the pharmacy records what it did against it. Clinical interventions publish back to the prescriber through the event outbox, and FHIR R4 keeps external hospital systems in step.
It runs the medication supply chain and the clinical checks around it: receiving an order, verifying it for safety, picking the right batch, labelling and dispensing it, and keeping stock, controlled substances and expiry under control. Eruntar's Pharmacy Module covers that whole span as one governed workflow rather than a billing screen with a stock list attached.
Twelve decision-support engines screen every order: allergy and cross-reactivity, drug interactions, dose range, therapeutic duplication, renal and hepatic adjustment, pediatric, geriatric, pregnancy, lactation, high-alert and controlled classification, and pharmacogenomics. The findings determine the verification level: automated for low-risk, pharmacist, clinical pharmacist as findings accumulate, or dual authorization for controlled and high-alert medicines.
The engines ship with curated screening tables built into the module, and each finding records its evidence source so a reviewing pharmacist knows what backed it. A commercial drug knowledge base such as First Databank, Lexicomp or Micromedex plugs into the same engine interface as a data change, not a rebuild. During beta we are explicit about this: the built-in tables are a screening floor, not a licensed clinical reference.
Yes, and the override is the point. A blocked pharmacist works around the system; a pharmacist who overrides with a recorded reason leaves evidence. Overrides capture the actor and reason, override rate is a standing metric, and your CDS policy can force dual authorization instead of an override for controlled and high-alert findings.
By batch, on an append-only ledger. Every movement writes a row with the previous and new balance, the actor and the reason, and database triggers reject any attempt to update or delete ledger history. Batches carry lot, expiry, manufacture date, supplier and unit cost, and picking is first-expiry-first-out with quarantined and recalled batches excluded automatically.
Yes. Locations are a real hierarchy of pharmacy, zone, cabinet, shelf and bin, and stock transfers between them run through a request and approval workflow that lands in the same ledger. Warehouse put-away, picking and binning flows are on the roadmap rather than in beta today.
Yes: purchase request, approval, purchase order, confirmation and goods receipt, with receiving handled by the same inventory engine that governs every other movement. Per-drug reorder points drive replenishment suggestions, and ABC, VEN and FSN analytics classify stock by consumption value, clinical criticality and movement frequency. Supplier contracts, invoices and price comparison are not in beta yet.
On an append-only register covering schedules II to V, with every receipt, dispense, return, destruction, adjustment and count recorded with a running balance and a witness alongside the performing user. Vault access and controlled dispensing require step-up re-authentication, daily reconciliation compares register to physical count, and configurable thresholds flag diversion patterns for an approval-gated investigation.
Initiating a recall quarantines every matching batch, which immediately removes them from first-expiry-first-out selection, and identifies the patients who already received the drug so they can be contacted. Recall status and the count of quarantined batches and identified patients are tracked to closure.
Temperature-controlled batches carry their required range, readings are recorded against them, and a logged excursion quarantines the affected batch automatically. Excursions over the last 30 days are a standing dashboard metric. Live broker-based IoT sensor ingestion is roadmap; today readings arrive through the device and integration surface.
Yes. Inbound HL7 v2 RDE^O11 pharmacy orders and NCPDP SCRIPT NewRx prescriptions are translated at the edge into the module's own order shape. Outbound, the module serves FHIR R4 MedicationDispense, Medication, InventoryItem and SupplyRequest with a CapabilityStatement. GS1 barcodes are parsed for GTIN, lot and expiry. Outbound HL7 dispense-result messaging and NCPDP network certification are roadmap items.
An advisory layer that drafts patient-counseling points and explains why a safety finding fired. During beta these are composed deterministically from the dispense record and the safety findings themselves, and are clearly labelled as not patient-ready: a pharmacist reviews everything before it reaches a patient. The AI layer cannot change a dispense, release an order or move stock, every interaction is audited and metered, and the governance register's safety rules run as executable tests. A licensed clinical model slots in behind the same versioned prompt registry.
43 granular capabilities across 9 categories, each tied to a stage of the medication lifecycle, assigned through 22 least-privilege role templates from chief pharmacist to regulatory inspector. 22 sensitive actions additionally require step-up re-authentication at the moment of use, including controlled dispensing, vault access, CDS override and emergency dispensing.
Yes. Prescriptions are read live from the Doctor Module over internal federation and are never copied, so there is one prescribing record and the pharmacy annotates it. Interventions publish back to the prescriber through the event outbox. Nurse administration round-trip and Billing charge capture are the next integrations on the roadmap.
The Pharmacy Module is currently in beta, and pricing will be announced at general availability. Beta access, including onboarding and close support, is arranged through our contact page.
As a beta. Hospitals and clinics can join the beta programme to run pharmacy operations on Eruntar with close support from the team, and shape the product before general availability. We are deliberately specific on this page about what is built and what is still roadmap.
The Pharmacy Module is in beta. Pricing will be announced at general availability. Beta partners get early access, onboarding support, and a direct line to the team building it.