Qiri · Confidential
Platform documentation
Internal & investor material. Sign in with your @qiri.ai Google account to continue.
Internal & investor material. Sign in with your @qiri.ai Google account to continue.
What has shipped, what is in build, what remains by phase, and the architecture decisions: made and still open. Live means in production today.
Running today on the console at console.qiri.ai unless noted. Detail per surface in Product surfaces.
ask.qiri.ai: self-serve signup, founding billing (monthly and annual), and a referral loop/api/translateaustralia-southeast1); the transcript lands on the consult record, and a bad transcript is refused rather than trustedconsult_payment entitlement, with a "Coming soon" fallback when off/counter in-store POS, entitlement-gated: card on Stripe Terminal, cash, and split tenders (cash + card, two cards); public /pay/<token> pagesstock_movement ledgerstatus.qiri.ai; public /support page; surface-scoped Help Centerqiri-clinical-pg, Sydney), physically separate from accounts/marketing; CMEK-encrypted with 90-day key rotationconsole.qiri.ai and my.qiri.ai on one load balancer: OWASP rule groups, per-IP rate limiting, adaptive DDoSWhat remains to be chosen, procured, or built, grouped by phase.
clinical schema: patient/script audit events, contract event hash-chains, consult consents)qiri-clinical keyring); extend to the remaining storesMade first, then open. Open items are ranked 1–3 by how much each blocks Phase 1, sits on the clinical safety path, or is costly to reverse.
| Decision | Outcome |
|---|---|
| Qiri vs the incumbent PMS | Qiri is the dispensing system of record + intelligence (2026-07-01). The connector remains as the coexistence and migration mode; it no longer defines the architecture. |
| Payments & billing stack | Stripe across the board: Billing (SaaS), Connect direct-charge (consults, orders), Terminal (counter). Live keys. Usage metering in-house; Lago retired. |
| Patient identity | Two records by design: patient_profile (app account, consent ledger) and clinical.patients (dispensing record); controlled Medicare + DOB match, no shared key, Medicare numbers never hashed. |
| Pricing authority | Qiri-authored pricing in contract_templates + entitlements, gated on org-admin acceptance before billing starts. |
| Patient-app intake default | Straight-through: an app submission runs platform intake + screening automatically under the org admin's standing authority, so no per-pharmacist service credential is required. A site can instead have scripts arrive unscreened, marked as such and screenable on demand; nothing is held out of the queue. The dispensing decision stays with the pharmacist either way. |
| Entitlements scope | Features, limits, and pricing are set on the org only; site rows carry usage. Grants are superseded, never deleted, so the entitlement history stays auditable. |
| Consult transcription residency | Consult audio is transcribed in-region on Google STT v2 (australia-southeast1), accepting its current limits (en-AU only, no speaker diarisation) rather than sending patient audio offshore. Unattributed transcript lines are rendered as such, never guessed. |
| Accounting integration shape | Record a normalised accounting_event at the source transaction; Xero/MYOB are downstream readers of that one feed, not code woven through the till. The integration can be built, replayed, or swapped without touching POS or stock. |
| Priority | Decision | Why it matters |
|---|---|---|
| 1 | Safety rules engine: HL7 CQL vs purpose-built deterministic rules | On the clinical critical path; CQL is standard but heavy for real-time hard-stops, and hard ceilings may not need it |
| 1 | Panel reconciliation: deterministic merge vs model-arbitrated vs pharmacist-resolved | It sits on the clinical path; a model arbitrating safety would weaken the gate principle |
| 1 | Context-graph store: Spanner Graph vs Neo4j-on-GKE | It's the moat; query shape, scale and ops burden differ a lot, and it's costly to migrate once full (BigQuery analytics over it is Phase 2) |
| 1 | Coexistence connector: on-prem agent vs cloud-hosted with site VPN | Gates every pilot that keeps its incumbent PMS; on-prem is more resilient and offline-friendly but more to maintain across sites |
| 2 | Translated counselling: validated phrase library vs LLM + back-translation + pharmacist sign-off | Patient safety: the pharmacist can't verify a language they don't read; high-risk dosing needs validated wording |
| 2 | Which patient languages per pilot region (and STT/TTS enablement) | Sets phrase-library scope and kiosk voice coverage for CALD communities; can be set close to each pilot. In-region STT is live but en-AU only today, so multilingual voice needs its own path |
| 3 | How much safety logic runs at the kiosk edge offline | Phase 2: determines safe-degradation behaviour when the WAN drops |
| 3 | Kiosk OEM: integrate an existing dispenser vs spec a custom cabinet | Phase 2 hardware: speed, capex, and regulatory surface |