Internal & investor material. Sign in with your @qiri.ai Google account to continue.
The neuro-symbolic Qiri reasoning engine beneath every surface, the symbolic safety gate on the clinical path, and the integration seams to the Australian pharmacy ecosystem.
Qiri operates inside a larger Australian pharmacy software stack: script rails, government endpoints, and clinical content it consumes but does not own. Within that stack, Qiri is the pharmacy's dispensing system of record; this section maps what stays, what Qiri replaces, and who supplies each layer.
Qiri is the dispensing system of record and the intelligence: the clinical decision, the label, the sale, and the stock ledger live in one platform (decided 2026-07-01; this supersedes the earlier layer-alongside framing). The rails beneath it all stay: eScript exchanges, PBS, RTPM, My Health Record, and the licensed clinical content that grounds every trace. For pharmacies not ready to switch, the dispense connector runs Qiri alongside the incumbent PMS: bi-directional FHIR R4 + HL7v2, Qiri reasons and counsels, the legacy system keeps its record. Two deployment modes, one platform; the connector is also the migration path.
Two owners control most of the rails the coexistence connector must speak to, and most of the systems Qiri replaces. This shapes the adapter strategy more than any single API does.
| Owner | Controls | Architecture implication |
|---|---|---|
| Telstra Health | Fred IT (Fred Dispense / Fred NXT), eRx Script Exchange, MedView Exchange, Corum, Aquarius | One vendor owns a major PMS and both eScript exchanges: a concentrated dependency. Hedge: multi-PMS adapters (§ market scope) and a second exchange path (MedView ↔ eRx interop). The exchanges remain rails even where Qiri replaces the PMS. |
| EBOS / Symbion | Minfos | Second-largest PMS, independent of Telstra. First-class adapter target alongside Fred so no single PMS owner can gate Qiri's reach. |
| Independent | LOTS · Z Software | Founder-owned, no exchange or wholesale entanglement, the simplest adapters to ship first and the lowest-friction coexistence path. |
Five bands, top to bottom: client surfaces → on-site edge → Qiri platform (application services · reasoning engine · safety gate) → integration bus → external & government integrations, with the data plane underneath. Dashed boxes are not yet procured or built.
The diagram shows the target data plane. Today, patient context lives in the clinical schema on its own CMEK-encrypted Cloud SQL Postgres instance (qiri-clinical-pg, Sydney), physically separate from the non-clinical qiri-users-pg; AlloyDB remains the target. Clinical ingress is live too: my.qiri.ai (patient API) and console.qiri.ai (console) terminate on one global external load balancer with Cloud Armor WAF in front of Cloud Run. The console also has a third front door: ask.qiri.ai serves the Ask Qiri Standalone product from the same build behind a Firebase Hosting front, with the surface branching on host. See Data model.
A model drafts the recommendation, the symbolic gate enforces the hard limits, the pharmacist makes the call, and every step is traced. The flow is identical at the console (Phase 1) or the kiosk (Phase 2); only the human's location differs.
sequenceDiagram autonumber participant SRC as Script source
PMS · eScript · kiosk participant ORCH as Orchestrator participant ENG as Reasoning engine
Claude · Gemini participant GATE as Symbolic safety gate
CQL · hard ceilings participant REV as Pharmacist
console / command centre participant DISP as Dispense + hardware participant GRAPH as Context graph + audit SRC->>ORCH: New script + patient history (PHI) Note over ORCH: normalize to FHIR R4 · pseudonymise (strip direct IDs) ORCH->>ENG: Clinical context: in-region (Vertex · VPC-SC) ENG->>ENG: Draft proposal · cite AMH / PBS ENG->>GATE: Proposal (advisory only) ORCH->>GATE: Script + patient facts (independent rule check) Note over GATE: Gate checks the script directly, not just the
LLM. Hard rules decide · LLM output never dispenses. alt Hard rule violated GATE-->>REV: HALT + full reasoning trace REV->>DISP: Hold · contact prescriber DISP-->>SRC: Write-back HOLD status (FHIR) else Within safe bounds GATE-->>REV: Recommendation + counselling note + trace REV->>DISP: Approve / modify DISP-->>SRC: Write-back status (FHIR) end REV-)GRAPH: Pharmacist action + outcome GATE-)GRAPH: Rules fired · model · citations Note over GRAPH: Every decision traced →
indemnity defence + network effect
A patient can lodge a script from the app and hear the result without a phone call: the submission enters the same queue, the same gate decides, and the outcome flows back. The whole loop is pharmacy↔patient; the dispensing decision never leaves the pharmacist.
sequenceDiagram autonumber participant APP as Patient app participant SUB as Submission API
my.qiri.ai · org url_token participant ORCH as Orchestrator
intake · screening participant REV as Pharmacist
review queue participant PUSH as Expo push APP->>SUB: Send eScript token + contact (no platform call yet) Note over SUB: status = submitted · the app polls the unguessable submission id alt Site mode: auto (default · straight-through) SUB->>ORCH: Intake + screen under the org admin's standing authority ORCH->>REV: Screened script drops into the review queue else Site mode: inbox SUB->>REV: Waits in the pharmacist Inbox REV->>ORCH: Manual Load under the pharmacist's own credential ORCH->>REV: Screened script drops into the review queue end Note over REV: Clinical decision is unchanged —
it passes the gate above. Pharmacist-in-the-loop holds. REV->>SUB: Stamp the decision back (approved / not approved) SUB-->>APP: Status poll surfaces the outcome (+ pay link when approved) SUB-)PUSH: Terminal decision → generic, drug-free notice PUSH-)APP: OS push, even with the app closed APP->>SUB: Pull the notifications inbox Note over SUB: notices are DERIVED on read from submissions + dispense orders:
no notices table to drift, only read/dismiss state is stored SUB-->>APP: Inbox feed + per-notice read/dismiss state
Straight-through intake automates only the intake step, and only when the site opts in (auto is the default; inbox keeps the manual Load). Every notice back to the patient is generic and drug-free; the status poll and the server-derived inbox are the source of truth, the push is a courtesy. The inbox itself is computed on read from submissions and dispense orders, so it can never disagree with the record; the only stored state is which notices the patient has read or dismissed (patient_notice_state).
Named GCP services per layer, phased.
What every Qiri surface is written in. Mainstream, widely-hired technologies: one language top to bottom keeps the team small and flexible.
| Layer | Technology | What it is | Why we chose it for Qiri |
|---|---|---|---|
| Language | TypeScript | JavaScript with static typing | Catches errors before they reach a pharmacist; one language across front and back end keeps the team small and flexible |
| UI framework | React | Component library for building interfaces | The deepest hiring pool in AU; the console, demo and outreach surfaces all share components |
| App framework | Next.js (App Router) | Full-stack React framework: routing, server rendering, and an API layer in one | A single codebase serves a fast marketing site and a secure app console; server-side rendering keeps patient data off the client |
| Runtime | Node.js | Server-side JavaScript engine | Mature and well-supported; runs anywhere, Cloud Run included |
| Component | GCP service | Role | Phase |
|---|---|---|---|
| Pharmacist console host | Cloud Run (qiri-console) | Serve Next.js console to in-store workstations at console.qiri.ai, behind the clinical WAF edge below. The Firebase Hosting front (qiri-console-host) serves ask.qiri.ai (Ask Qiri Standalone) in production from the same build and doubles as the console's rollback path | P1 |
| Patient API host | Cloud Run (qiri-patient-api) | Patient clinical API / BFF at my.qiri.ai, behind the same WAF edge; ingress locked to the load balancer (no direct run.app access) | P1 |
| Clinical WAF edge | Global external ALB + Cloud Armor | One static IP fronts my.qiri.ai + console.qiri.ai: managed TLS, HTTP→HTTPS redirect, OWASP WAF rules, per-IP rate limiting, adaptive L7 DDoS, serverless NEGs to Cloud Run | P1 |
| Identity | Firebase Auth + Cloud SQL Postgres | Pharmacist + patient auth on Cloud Run behind the global load balancer: email-link sign-in, RS256 token verification, org/site/role model, onboarding. Service-account least privilege; AHPRA-linked roles. Consolidating onto Identity Platform + Cloud IAM is a later step. See Backend API for endpoints and table structures. | P1 |
| Application services | Cloud Run (or GKE Autopilot) | Dispense orchestration, counselling, integration, audit | P1 |
| Eventing | Pub/Sub, Eventarc, Workflows | Dispense events, async pipelines, orchestration | P1 |
| API management | Apigee | Developer portal, quota monetisation, advanced routing (third-party API consumers) | P2 |
| Application services (kiosk + command centre) | Cloud Run | Kiosk orchestration, command centre oversight | P2 |
| Component | GCP service | Role | Phase |
|---|---|---|---|
| Reasoning models | Vertex AI: Claude + Gemini | Claude: clinical reasoning, counselling, patient-level translation. Gemini: multimodal triage, OCR, high-volume. | P1 |
| Model router | Cloud Run service | Route per task type / cost / latency. Failover applies to OCR / triage; clinical-reasoning proposals are not silently swapped between models. | P1 |
| Specialist orchestrator | Cloud Run service | Routes a script to the right domain-scoped specialist agent, or convenes a panel and reconciles their proposals into one advisory recommendation, before the safety gate. How proposals are reconciled is open (Open decisions). Adding a domain is config, not infra. | P1 |
| Symbolic safety layer | Custom CQL rules engine on Cloud Run | Hard ceilings + clinical rules gate every proposal. Source of truth for "do not dispense". Engine choice (CQL vs purpose-built) is open; see Open decisions. | P1 |
| Knowledge retrieval (RAG) | Vertex AI Search + Vector Search | AMH, eTG, PBS schedule, clinical guidelines grounding | P1 |
| Document OCR | Document AI | Script / label extraction at kiosk and console | P1 |
| Trace + context graph | Append-only trace store (Postgres now); context graph + BigQuery analytics later | Structured decision traces, the compounding moat: capture from day one, warehouse at scale | P1 P2 |
| Voice | Speech-to-Text v2 / Text-to-Speech | Live for consult transcription: STT v2 at the australia-southeast1 regional endpoint, en-AU only, and no speaker diarization in region, so transcript lines render unattributed by design. Kiosk voice counselling and TTS accessibility follow | P1 P2 |
| Component | GCP service | Role | Phase |
|---|---|---|---|
| Operational / PHI store | Cloud SQL (Postgres) today; AlloyDB target | Scripts, patients, transactions. The clinical schema lives on a dedicated CMEK instance (qiri-clinical-pg, Sydney), physically separate from the non-clinical qiri-users-pg (outreach, demo). Field-level AES-256-GCM on patients.id_number | P1 |
| Real-time state | Firestore | Demo configs + WebRTC consult signaling (SDP/ICE); no PHI. (Console auths via a Firebase ID token — no server-side session state) | P1 |
| Object store | Cloud Storage (CMEK) | Documents, telepharmacy recordings, images | P1 |
| Cache / sessions | Memorystore (Redis) | Low-latency lookup cache (target; nothing uses Redis today, the console is stateless on Firebase ID tokens) | P2 |
| Keys & secrets | Cloud KMS (CMEK) + Secret Manager | Customer-managed encryption (live on qiri-clinical-pg, 90-day auto-rotation), credential storage | P1 |
| Compliance perimeter | VPC Service Controls, Private Service Connect, DLP API, Security Command Center | Data exfil prevention, PHI scanning/redaction, posture | P1 |
| Observability | Cloud Logging / Monitoring / Trace + Audit Logs | Immutable audit trail, alerting, distributed tracing | P1 |
| CI/CD + IaC | Cloud Build, Artifact Registry, Cloud Deploy, Terraform | Reproducible, auditable deploys | P1 |
| Analytics | BigQuery | Population health (de-identified via DLP API), A/B, ops | P2 |
Government endpoints (PBS, My Health Record, PRODA, RTPM, AHPRA) are external integrations, not vendor choices. Full list with links in Integration reference.
Phase 2: the same clinical path, pharmacist now remote at the command centre. The hardware is partner-built (ScriptPro / Parata / Wellmation); Qiri is the intelligence layer. Edge compute provides offline safety fallback: if the WAN drops, the kiosk safe-denies Rx requiring sign-off and queues for review.