Pharmacy architecture and workflows
Operator and customer surfaces, conceptual relationships, bounded GraphQL operations, and human-controlled pharmacy lifecycles.
Application surfaces
The public application provides the pharmacy storefront at /, cart at /cart, and checkout at /checkout. Public queries return enabled locations and non-prescription catalog products. A guest cart uses an opaque token; the stored form is hashed. A successful order returns a separate token accepted by the bounded guestPharmacyOrder projection. Current source has no public order-status route or storefront helper that consumes that projection, so it is an API boundary rather than a complete customer order-tracking surface.
Authenticated operators use /dashboard/platform/* routes:
| Area | Current routes and work |
|---|---|
| Prescriptions | Queue, intake, and prescription task pages for source verification, pharmacist review, dispensing authorization, lot selection, and dispensing evidence |
| Inventory | Lot/expiry/cold-chain queue, controlled receipt, lot task, quantity adjustment, temperature-excursion evidence, and movement history |
| Recalls | Recall queue and recall task for opening a bounded recall and quarantining affected lots |
| Orders | Order queue and task pages for immutable lines, payment state, and controlled fulfillment transitions |
| Patients and POS | Patient-safe directory/detail and a location-scoped non-prescription POS catalog |
| Integrations and evidence | Provider state, audit timeline, outbox timeline, failed-delivery queue, and permissioned replay |
Generic Keystone administration still exists for permitted configuration records. Consequential lifecycle and evidence records omit raw create/update/delete GraphQL fields; focused platform pages call named operations instead.
Conceptual data model
- Business and staff: organizations, locations, memberships, users, and roles establish tenant and location authority.
- Medication and catalog: drug references carry bounded medication identity such as NDC snapshots; products connect that reference to pharmacy-owned SKU, availability, price, tax, prescription requirement, and cold-chain policy.
- Patients and prescribers: patient profiles, prescribers, consent records, prescriptions, items, reviews, refills, and transfers keep identity, authorization, consent, and medication facts explicit.
- Inventory and safety evidence: suppliers, lots, immutable movements, recalls, temperature excursions, and human approvals connect what was received, held, quarantined, released, recalled, or dispensed.
- Commerce and fulfillment: carts and items lead to immutable order lines, payment sessions/payments, fulfillment, and guest-safe order access. Prescription requirement, NDC, name, quantity, and price are snapshotted where needed.
- Operations evidence: audit and outbox events identify the actor, aggregate, event key, and bounded metadata without using raw patient, prescription, payment, or provider payloads as the audit record.
Model presence is not a capability claim. Capability comes from a routed, permissioned operation with a defined lifecycle, transaction, projection, test, and operational owner.
Bounded GraphQL queries
Customer queries are limited to public locations/catalog, token-scoped cart, enabled payment choices, and token-scoped guest order. Operator projections cover the catalog queue, POS catalog, setup options, prescription/inventory/recall/order queues and tasks, patient-safe views, provider state, summary counts, onboarding state, audit timeline, and outbox state.
Those projections deliberately omit patient contact and birth details from patient-safe views; provider credentials and adapter function names; payment payload data; guest-token hashes; audit metadata; and outbox payload/error text. Requesting an omitted field fails at the schema boundary.
Named mutations
Current source registers these pharmacy operations:
- Customer commerce:
createPharmacyCart,addPharmacyCartItem,updatePharmacyCartItem,removePharmacyCartItem,initiatePharmacyPaymentSession, andsubmitPharmacyOrder. - Prescription and patient requests:
intakePharmacyPrescription,recordPrescriptionReview,authorizePrescriptionDispensing,recordPrescriptionDispensing,requestPrescriptionRefill,requestPrescriptionTransfer, andapprovePrescriptionTransfer. - Inventory, recall, and cold chain:
receivePharmacyInventoryLot,adjustPharmacyInventoryLot,openPharmacyRecall,quarantineRecallLots, andrecordTemperatureExcursion. - Operations:
transitionOrderFulfillment,replayPharmacyOutboxEvent,runPharmacyOnboarding, andsetPharmacyOnboardingStatus.
These are application operations, not declarations that an external pharmacy network, insurer, wholesaler, tax service, sensor, delivery provider, or regulator accepted the result.
Prescription and dispensing path
The controlled path is intake -> source verification -> pharmacist review -> approval or rejection -> dispensing authorization -> eligible lot selection -> dispensing evidence. A prescription cannot jump from draft to dispensed. Terminal records do not re-enter active workflow. Dispensing verifies the authorized prescription, location, product/lot match, expiry, available quantity, quarantine quantity, recall/cold-chain eligibility, pharmacist permission, attestation, and reason.
Software checks do not make a prescription valid or dispensing lawful. The authorized pharmacist remains responsible for clinical and legal review, identity, prescriber authority, substitution, counseling, controlled-substance rules, jurisdictional records, and the physical act of dispensing.
Lot, recall, and cold-chain path
Receipt creates lot identity, quantity, approval, movement, audit, and outbox evidence together. A cold-chain lot without complete evidence starts quarantined. A temperature excursion records the observed range and time, quarantines the lot, marks evidence incomplete, and creates disposition evidence. Opening a recall binds a recall identity and selected tenant-owned lots; quarantining the recall moves each affected lot to a recalled/quarantined state and records immutable movements.
The implementation records evidence supplied by authorized people or adapters. It does not ingest calibrated sensor data, validate a shipping lane, identify every affected patient, submit regulatory reports, or prove that a physical product was removed from circulation.
Commerce and fulfillment path
The public cart rejects any product whose prescription requirement is not none. Checkout re-reads server-owned product, lot, location, payment, amount, and availability facts; creates immutable order and line snapshots; decrements eligible inventory in a transaction; and records audit/outbox evidence. Current concurrency evidence used database locks so only one competing one-unit checkout committed, but each deployed database and workflow still needs load and failure testing.
Order fulfillment is separate from prescription review and dispensing. A paid OTC order can move through fulfillment states; a medication order cannot use a generic fulfillment transition to bypass pharmacist-controlled dispensing.