What is PhytoMedic? What does V1 actually cover?
Line-by-line: in, out, future phase. One master count.
V1 does not block V1.5→V5. How reuse lowers future cost.
Why data collection must start in V1. Pipeline explained.
Pharmacy + Public Finder in V2. ROM estimates. Timelines.
Fixed vs assumption vs discovery. $28,902 final V1 price.
| Feature | ✅ V1 — Fabbi Builds | Future Phase |
|---|---|---|
| Auth & Multi-tenant | Biometric, device binding, WebAuthn/Passkeys, JWT RS256, session mgmt | SSO/OAuth2 (V1.5) |
| KYC & QES | Manual KYC + D-Trust enrollment, QES signing & verification | AI KYC (V1.5), SwissSign eval |
| Presence Check | Geofence GPS + rotating QR + liveness selfie, check-in/out | — |
| Patients | Search, register, patient profile, consent management, visit history (PAT-001→005) | Therapy diary (V1.5) |
| Site Management | Site catalog, site details, access requests, site configuration, physician approval (SITE-001→005) | — |
| Booking & Appointments | Location search, booking flow, slot selection, calendar, create/reschedule/cancel, doctor availability, no-show tracking (BOOK-001→005, APT-001→008) | — |
| Prescriptions | ICD-10, product select, dosage validation, preview, draft, history, QES-sign | Templates (V1.5) |
| Pharmacy Routing | Cannaleo + HiGreen API, product catalog, normalization, routing, status | Fallback rules (V2) |
| Cannametrics Foundation | 7 tables: catalog, snapshots, price history, outcomes, V3 read API — data collection from Day 1 | Analytics UI (V3) |
| Doctor Portals | iOS + Android (React Native, native) + Responsive Web (React) + PWA (WEB-003, installable) | — |
| Admin Portal | User mgmt, site admin dashboard, compliance dashboard | Pharmacy onboarding ext. (V2) |
| Audit & Compliance | Immutable hash-chained audit, auth/presence/prescription logs, compliance reports | Regulatory export (V1.5) |
| Notifications | Multi-channel push (iOS/Android) + email + in-app + templates | SMS (V1.5) |
| Drug Safety & Security | Drug interaction database (DRUG-001, BtMG caps + duplicate detection) · Secrets management (HashiCorp Vault) | — |
| Infrastructure | Dev environment, CI/CD, GDPR config, web app shell (WEB-001/002), PWA (WEB-003) | — |
| Pharmacy Onboarding | Basic pharmacy registration & verification (PHARM-ONB) | Full portal (V2) |
| What's out of V1 | Phase | How it extends V1 |
|---|---|---|
| Patient Portal | V1.5 | New patient role + new UI on existing V1 APIs — zero schema change |
| Pharmacy Portal + Public Finder Lite Doctor finder, pharmacy finder, public product catalog |
V2 | Pharmacy org type + PHARMACIST role + inventory APIs. Includes lightweight public-facing finder (doctor/pharmacy/product) — per Alexander's suggestion to pull forward from V5. |
| Pharmacy Portal + Public Finder Lite Doctor finder, pharmacy finder, product catalog (public) |
V2 | Pharmacy org type + PHARMACIST role + public-facing finder. Reuses V1 product catalog data. |
| Cannametrics Dashboards & Analytics | V3 | Read-only analytics on V1 tables — no migration needed, data already collected from Day 1 |
| Manufacturer Portal | V4 | Manufacturer org type on same multi-tenant model |
| Full Public Growth Layer SEO engine, content platform, GEO pages, calculators, community | V5 | Separate marketing site — no clinical DB coupling. Basic finder already in V2. |
| E-Rezept / Gematik TI | V2+ | FHIR-compatible architecture prepared in V1. Client obtains Zulassung independently. |
| Extensibility Axis | V1 Design Decision | Impact on Future Phases |
|---|---|---|
| Multi-tenant org_id | Every entity carries org_id from day 1 | New portal = new role + new UI. No schema change. |
| RBAC role model | DOCTOR, ADMIN, COMPLIANCE, SUPER_ADMIN defined in V1 | Adding PATIENT, PHARMACIST, MANUFACTURER = role additions only |
| API-first design | All features exposed as typed REST APIs | Patient Portal (V1.5) = new frontend on existing APIs — ~60% of work is reuse |
| Modular Monolith | Domain modules with clear boundaries | Extractable to microservices if scale demands — no lock-in |
| Cannametrics tables (7 tables) | V1 writes structured data from Day 1, continuously | V3 = read-only analytics on data already collected. No migration ever needed. |
| i18n scaffolded | EN/DE locale support from V1 | Multi-language content = translations only, no code change |
| Product normalization | Cannaleo + HiGreen data normalized to internal model | V2 Pharmacy Portal + V3 Cannametrics reuse same catalog — ~40% effort saved |
V3 Analytics needs historical data — price trends, availability patterns, routing outcomes — that can only be collected over months of real usage. You cannot retroactively generate this data.
V1 writes to 7 Cannametrics tables from Day 1. By the time V3 launches, months of real market data are already stored and ready for analytics — no migration, no backfill.
| Table | SOW ID | What it captures |
|---|---|---|
| product_catalog | CANNA-001 | Schema + sync service foundation |
| catalog sync service | CANNA-002 | 15-min Cannaleo/HiGreen poll |
| pharmacy_availability_snapshots | CANNA-003 | Supply availability over time |
| price_history | CANNA-004 | Append-only price tracking |
| prescription_product_data | CANNA-005 | Demand by product (anonymized) |
| routing_outcomes | CANNA-006 | Routing performance + idempotency |
| V3 Read API (internal) | CANNA-007 | Read-only endpoint for V3 analytics team |
| Foundation | Phases | Reduction |
|---|---|---|
| Multi-tenant org_id | V1.5V2V3V4 | 10–15% |
| RBAC role model | V1.5V2V4 | 5–10% |
| API-first design | V1.5 | 30–40% |
| Cannaleo/HiGreen APIs | V2V3 | 15–20% |
| Audit & compliance | All | 5–10% |
| Cannametrics 7 tables | V3 | 25–35% |
| Module | Type | Note |
|---|---|---|
| Auth, KYC (manual), Presence | Fixed | Fully specified |
| Booking, Appointments, Audit | Fixed | Fully specified |
| Cannametrics data collection | Fixed | Schema + jobs defined |
| QES (D-Trust) | Fixed + Dep. | ⚠ D-Trust sandbox at kickoff |
| Pharmacy routing | Fixed + Dep. | ⚠ API docs by Week 1 |
| Drug interaction DB | Assumption | Source TBD |
| Advanced QES edge cases | Discovery | May generate CRs |
| V1 Foundation | Reused In | Effort Reduction (est.) | Visual |
|---|---|---|---|
| Multi-tenant architecture (org_id) New portal = new role + new UI. No schema change. |
V1.5 V2 V3 V4 | ~10–15% per version | |
| RBAC role model Adding PATIENT, PHARMACIST = role additions only. |
V1.5 V2 V4 | ~5–10% per version | |
| API-first design (all features as REST APIs) V1.5 Patient Portal calls existing V1 APIs — backend largely complete. |
V1.5 | ~30–40% backend effort saved for V1.5 | |
| Cannaleo / HiGreen integrations Integration code reused in V2 pharmacy operations. |
V2 V3 | ~15–20% of pharmacy integration scope | |
| Product normalization layer (PROD-001→004) Normalized catalog reused across pharmacy, analytics, and manufacturer modules. |
V2 V3 V4 | ~10–15% of product-related scope | |
| Audit & compliance foundation All portals write to same audit trail — no rebuild per phase. |
All versions | ~5–10% per version | |
| Cannametrics data foundation (7 tables, collecting from Day 1) V3 reads data already accumulated during V1 + V2 operation — no migration needed. |
V3 | ~25–35% of V3 analytics scope | |
| Pharmacy routing logic Core routing rules extended — not rebuilt — in V2 pharmacy portal. |
V2 | ~10–15% of V2 routing scope |
| Category | Items | Confidence |
|---|---|---|
| Fixed Scope Clear client requirements, no dependency uncertainty |
Auth (AUTH-001~006), KYC (KYC-001~007), QES (QES-001~005), Presence (PRES-001~007), Patient (PAT-001~005), Appointments (APT-001~008), Booking (BOOK-001~005), Infrastructure (INFRA-001~003), Admin (ADMIN-001~003), Audit (AUDIT-001~005) | High — requirements documented |
| Assumption-Based Fabbi-proposed, details may evolve in Sprint 0 |
Cannametrics schema design (CANNA-001~007), Notification channels (NOTIF-001~004), Compliance dashboard format (ADMIN-003), Presence check UX flow, Web app shell (WEB-001~002), Drug interaction DB source (DRUG-001), Pharmacy onboarding flow (PHARM-ONB) | Medium — adjustable in Sprint 0 |
| Discovery-Dependent Known unknowns — resolved through API access & regulatory consultation |
D-Trust API behavior & edge cases, Cannaleo/HiGreen API rate limits & schema, BtMVV validation rules, GDPR Art.9 specifics, Drug interaction DB licensing, QES multi-device flows | Variable — may generate CRs |
| # | Item | Owner | Deadline | Risk if delayed |
|---|---|---|---|---|
| 1 | D-Trust sandbox credentials | Cannabis Ärzte | Before kickoff | Blocks QES module entirely |
| 2 | Cannaleo API documentation + sandbox | Cannabis Ärzte / Cannaleo | Week 1 | Delays pharmacy routing sprint |
| 3 | HiGreen API documentation + sandbox | Cannabis Ärzte / HiGreen | Week 1 | Delays pharmacy routing sprint |
| 4 | AWS account (Frankfurt region) setup | Fabbi (client access) | Sprint 0 | No major risk — internal |
| 5 | Contract signing + 30% down payment ($8,671) | Cannabis Ärzte | Before kickoff | Blocks project start |