Qiri · Confidential

Platform documentation

Internal & investor material. Sign in with your @qiri.ai Google account to continue.

Qiri
Qiri · Architecture

Reference architecture

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.

GCP · australia-southeast1 Claude + Gemini · Vertex AI FHIR R4 / HL7v2 coexistence connector PBS + My Health Record

Ecosystem & vendor landscape

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.

System of record, with a coexistence bridge

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.

Patient appsAdherence · reminders
Qiri patient app (in build: scripts wallet, consults, payments) · MedAdvisor (ASX:MDR) & similar as outbound adherence surfaces, above the gate
PharmacistPractice + accreditation
QCPP audit standard · PSA practice standards, the audit trail (Clinical decision flow) should map to QCPP
QiriSystem of record · decision · counsel · POS · stock
Clinical reasoning engine + symbolic safety gate, and the dispensing record itself: review, label, payment, stock ledger (System architecture and Clinical decision flow).
Incumbent dispensing PMSCoexistence mode
Fred · Minfos · Corum · Z · LOTS · Aquarius: replaced where the pharmacy switches to Qiri; connected 2-way by the dispense connector where it doesn't (System architecture, edge band)
Prescription railseScript transport
eRx · MedView (now interoperable) · Active Script List, the script source into the orchestrator
Regulatory monitoringControlled drugs
RTPM, state-fragmented: SafeScript (VIC), QScript (QLD), NSW/SA/WA/TAS/NT, auto-checked as part of the trace
Clinical contentGrounding sources
AMH · eTG · MIMS · NPS, licensed into the RAG grounding layer; cited in every trace
Supply chainWholesale
EBOS/Symbion · Sigma · API, connected through stock purchase orders today (wholesaler CSV); kiosk replenishment in Phase 2

Vendor concentration: an integration constraint

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.

OwnerControlsArchitecture implication
Telstra HealthFred IT (Fred Dispense / Fred NXT), eRx Script Exchange, MedView Exchange, Corum, AquariusOne 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 / SymbionMinfosSecond-largest PMS, independent of Telstra. First-class adapter target alongside Fred so no single PMS owner can gate Qiri's reach.
IndependentLOTS · Z SoftwareFounder-owned, no exchange or wholesale entanglement, the simplest adapters to ship first and the lowest-friction coexistence path.

System architecture

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.

Bands Phase 1 · Prove Phase 2 · Extend External / government Safety gate Placeholder · to procure
Flow Sync request Async event / trace Live audio / video Tinted panel = trust boundary Clinical safety gate
Pharmacist ConsolePhase 1 · in-store · installable tablet till
Command CentrePhase 2 · remote
Patient KioskPhase 2 · self-service
Patient AppPhase 1 · script lodge
↓  clinical events  ↓

On-site Edge

semi-trusted zone
Dispense ConnectorFHIR R4 · HL7v2
Kiosk Edge Runtimeoffline cache · local safety
Kiosk Hardwarepartner-built
Qiri

Qiri Platform

GCP · australia-southeast1 · VPC-SC perimeter
Application services · Cloud Run
Dispense Orchestrator
Integration
Consent & Audit
Reasoning engine · neuro-symbolic
Claude · Vertex AIreasoning · counselling
Gemini · Vertex AImultimodal · OCR · scale
Model Router
Grounding · RAGAMH · eTG · PBS
★ SYMBOLIC SAFETY GATECQL rules · hard ceilings: every model output passes here before any dispense

Government & Partners

external integrations
PBS · My Health RecordPRODA · NASH PKI
RTPMcontrolled drugs · per state
AHPRAregistration
Billing & MeteringStripe Billing · in-house metering
Payment GatewayStripe
Telepharmacy AVWebRTC · Firestore signaling · TURN relay · in-region transcription
QiriQiri Integration Bus  ·  API Gateway · Global LB + Cloud Armor WAF · Identity Platform
OAuth / OIDC
AlloyDBPHI · scripts
MOATContext Graphdecision traces
BigQueryPhase 2 · de-identified
Cloud Storagedocs · A/V
Cloud KMSCMEK · secrets

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.

Clinical decision flow: the gate

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

Patient intake & outcome loop

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).

Component reference

Named GCP services per layer, phased.

Application stack (languages & frameworks)

What every Qiri surface is written in. Mainstream, widely-hired technologies: one language top to bottom keeps the team small and flexible.

LayerTechnologyWhat it isWhy we chose it for Qiri
LanguageTypeScriptJavaScript with static typingCatches errors before they reach a pharmacist; one language across front and back end keeps the team small and flexible
UI frameworkReactComponent library for building interfacesThe deepest hiring pool in AU; the console, demo and outreach surfaces all share components
App frameworkNext.js (App Router)Full-stack React framework: routing, server rendering, and an API layer in oneA single codebase serves a fast marketing site and a secure app console; server-side rendering keeps patient data off the client
RuntimeNode.jsServer-side JavaScript engineMature and well-supported; runs anywhere, Cloud Run included

Compute, API & identity

ComponentGCP serviceRolePhase
Pharmacist console hostCloud 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 pathP1
Patient API hostCloud 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 edgeGlobal external ALB + Cloud ArmorOne 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 RunP1
IdentityFirebase Auth + Cloud SQL PostgresPharmacist + 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 servicesCloud Run (or GKE Autopilot)Dispense orchestration, counselling, integration, auditP1
EventingPub/Sub, Eventarc, WorkflowsDispense events, async pipelines, orchestrationP1
API managementApigeeDeveloper portal, quota monetisation, advanced routing (third-party API consumers)P2
Application services (kiosk + command centre)Cloud RunKiosk orchestration, command centre oversightP2

Reasoning engine (neuro-symbolic)

ComponentGCP serviceRolePhase
Reasoning modelsVertex AI: Claude + GeminiClaude: clinical reasoning, counselling, patient-level translation. Gemini: multimodal triage, OCR, high-volume.P1
Model routerCloud Run serviceRoute per task type / cost / latency. Failover applies to OCR / triage; clinical-reasoning proposals are not silently swapped between models.P1
Specialist orchestratorCloud Run serviceRoutes 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 layerCustom CQL rules engine on Cloud RunHard 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 SearchAMH, eTG, PBS schedule, clinical guidelines groundingP1
Document OCRDocument AIScript / label extraction at kiosk and consoleP1
Trace + context graphAppend-only trace store (Postgres now); context graph + BigQuery analytics laterStructured decision traces, the compounding moat: capture from day one, warehouse at scaleP1 P2
VoiceSpeech-to-Text v2 / Text-to-SpeechLive 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 followP1 P2

Data & security

ComponentGCP serviceRolePhase
Operational / PHI storeCloud SQL (Postgres) today; AlloyDB targetScripts, 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_numberP1
Real-time stateFirestoreDemo configs + WebRTC consult signaling (SDP/ICE); no PHI. (Console auths via a Firebase ID token — no server-side session state)P1
Object storeCloud Storage (CMEK)Documents, telepharmacy recordings, imagesP1
Cache / sessionsMemorystore (Redis)Low-latency lookup cache (target; nothing uses Redis today, the console is stateless on Firebase ID tokens)P2
Keys & secretsCloud KMS (CMEK) + Secret ManagerCustomer-managed encryption (live on qiri-clinical-pg, 90-day auto-rotation), credential storageP1
Compliance perimeterVPC Service Controls, Private Service Connect, DLP API, Security Command CenterData exfil prevention, PHI scanning/redaction, postureP1
ObservabilityCloud Logging / Monitoring / Trace + Audit LogsImmutable audit trail, alerting, distributed tracingP1
CI/CD + IaCCloud Build, Artifact Registry, Cloud Deploy, TerraformReproducible, auditable deploysP1
AnalyticsBigQueryPopulation health (de-identified via DLP API), A/B, opsP2

Market scope: Australia first, built to extend

  • AU-regulated: TGA, AHPRA, PBS, My Health Record, state RTPM: every integration named here is an Australian endpoint.
  • Market-pluggable: government, e-prescription, and drug-knowledge integrations are swappable adapters behind the integration bus.
  • US entry: NCPDP SCRIPT, Surescripts, DEA/state PDMP, First Databank: a new adapter set plus compliance profile, core architecture unchanged.
  • Per-region config: PHI residency, audit trail, and safety gate are set per market.

External vendors

  • Anthropic Claude: third-party model, served on Vertex but under Anthropic terms.
  • Stripe: Billing for SaaS subscription revenue (pharmacy → Qiri), including the Ask Qiri Standalone per-user subscriptions, and Connect for consult payments (patient → pharmacy), plus the in-person card reader (Terminal) at the store counter. Live keys on all three. Webhooks terminate on the console behind a dedicated WAF allow rule. Usage metering is in-house (Lago retired).
  • Drug-knowledge licences: AMH / eTG / MIMS.
  • Kiosk OEM hardware: ScriptPro / Parata / Wellmation.
  • eScript exchange: eRx.
  • PMS dispense vendors: the six AU incumbents (Ecosystem & vendors).
  • Patient notifications: Expo push (OS push; generic, drug-free notices only) and Resend (email). Twilio SMS is planned; the console's SMS action is a mock today.

Government endpoints (PBS, My Health Record, PRODA, RTPM, AHPRA) are external integrations, not vendor choices. Full list with links in Integration reference.

Patient kiosk: edge & hardware

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.

Patient Kiosk

secure cabinet · partner-built hardware
Patient I/O
Touchscreenno keyboard
ScannerMedicare · ID · eScript QR
Camera · mic · speakertelepharmacy A/V
Label + receipt
Edge Runtimeoffline cache · local safety fallback · orchestration
Dispense mechanism
OTC / S2-S3 vending
Robotic Rx dispense
Payment GatewayStripe
online: edge sends full reasoning to platform, receives approved dispense  ·  live A/V counselling bridges to the command centre  ·  WAN down: edge falls back to local rules, safe-deny + queue
Qiri platform documentation · v1.2 · 2026-07-23. Brand tokens from design-system/qiri-tokens.css. Source lives in design-site/src/; edit there, then run node build.mjs.
© 2026 Qiri.ai – All rights reserved
scroll to zoom · drag to pan · Esc to close