# 09 — Product & Packaging View: What We Sell, To Whom

**Role:** healthcare-software product strategy input to the ERP ↔ LIS ↔ HIS ↔ OBGY architecture decision.
**Sources actually read:**
- `/home/moonui/public_html/hms-feasibility-report.html` — HIS feasibility study v2 (readiness scorecard, 4 governing decisions, Phase 0 package, roadmap, generalization register).
- `/home/amrtechogate/public_html/obgy-erp-analysis.md` — full OBGY legacy analysis (§00 technical architecture, §02 visits/appointments, §90 master ERD, §95 ERP migration blueprint incl. integration contracts §2 and phases §3, risk register §4).

Everything below is traceable to those two files; market-sizing and competitor statements are explicitly marked **(inference)**.

---

## 1. The four assets on the table

| Asset | Status | Evidence |
|---|---|---|
| Moon ERP platform | 15 modules in production, Laravel 12 + Angular 21 | hms-feasibility-report.html hero meta; "15 موديول" |
| `Modules/LIS` | Production, the most complex module: 135 migrations, ~311 routes; cashier shifts + Z report, safes with auto ledger accounts, insurance contracts, monthly billing, **NPHIES (eligibility/approvals/claims, FHIR)**, B2B reference-lab portal with live customers | hms report §1, §3 rows "كاشير الاستقبال", "التأمين والمطالبات + NPHIES"; decision-1 note (B2B patients with live clinical rows) |
| `Modules/HIS` | Approved, not built. Roadmap: Phase 0 foundation 3–5 person-weeks; Phase 1 outpatient 8–14; Phase 2 inpatient 10–16; Phase 3 extensions 4–10 each. Hard gaps: appointments engine 1/10, beds/ADT/folio 0–1/10 | hms report §6 roadmap, §7 scorecard |
| OBGY legacy system | 312 tables, zero FKs, PHP 5.6 / Smarty / RedBeanPHP; full migration blueprint to `Modules/Obgy` exists (312 → ~85 tables, phases P0–P7, risk register R1–R12) | obgy-erp-analysis.md §00, §95 |

Key qualifier on the OBGY asset: **the legacy code is unsellable as-is** — confirmed SQL injection in search/report controllers (`patients.php` ~311–419, `financialreport.php`, `visits.php`), unauthenticated CORS-open mobile API (`mobileservices.php`, auth calls commented out), DB dumps inside the web root (`core/db_backups/`, `_db/`), PHP 5.6.40 EOL since 2018 (obgy-erp-analysis.md §5, §6). The sellable asset is the **domain model + Arabic clinical vocabularies + the migration blueprint**, not the code.

---

## 2. Product tiers — one platform, license-keyed module sets

The architectural rule that makes tiering possible is already decided (hms report, Decision 2): `HIS` imports `LIS/Accounting/HRM`; **`LIS` never imports `HIS`** (feedback via existing events `LabResultReleased` / `LabRequestCompleted`), so LIS stays sellable standalone.

### Tier 1 — Moon Lab (sells today)
- Modules: `Core` + `Accounting` + `Modules/LIS`.
- Buyers: standalone labs, lab chains, B2B reference labs (portal exists with live customers — decision-1 analysis: 15 B2B patients with 15 requests / 18 samples / 45 results / 16 invoices on dev env).
- Zero build. This tier is the company's current revenue engine.

### Tier 2 — Moon Clinic (HIS Phase 1)
- Adds `Modules/HIS` core: appointment engine, `Encounter`, folio, reception cashier (reuses LIS safes/shifts), generalized insurance/price lists (generalization register row "قوائم الأسعار المسماة + التغطية التأمينية" — lifted from LIS, polymorphic items).
- Buyers: outpatient clinics and polyclinics — the widest customer count in Egypt/Saudi **(inference)**.
- Build: 8–14 person-weeks after the 3–5-week Phase 0 (hms report figures, unchanged).

### Tier 3 — Moon Women's Health (Clinic + `Modules/Obgy`)
- Adds the specialty plugin per blueprint §95: `Pregnancy` + `AntenatalVisit` (3-generation merge of `ancsheet`/`mainantenental`/`followup`), `GynaSheet`, `InfertilityFile`, `IvfCycle` + `FollicleMeasurement` + stage sub-tables (`OocyteRetrieval`, `EmbryoTransfer`, `Cryopreservation`, `EndometrialPrep`, `CycleOutcome`), `SemenAnalysis`/`HormoneResult`, `ImagingStudy` (US/TVS/HSG/4D incl. 3.1 GB sonar media), `EndoscopyProcedure`, `OperativeNote`/`SurgicalBooking`, history engine (`ph*` domain), follow-up cards, medical board.
- Buyers: OB/GYN clinics, IVF/ICSI/IUI centers.
- Build: blueprint phases P1–P4 (each sized L); **the analysis is done** — 312 tables fully documented, model mapping complete, ETL risk register written (R1–R12).
- Launch customer: the legacy OBGY clinic itself (see §6).

### Tier 4 — Moon Hospital (HIS Phase 2 + 3)
- Adds inpatient: wards/rooms/beds + bed map, ADT, nightly bed-day charge job → folio, deposits/advance payments, basic nursing station (HIS roadmap Phase 2, 10–16 person-weeks); then Phase 3 extensions (clinical pharmacy on existing `Inventory`/POS, OR/radiology via the same `CreateLabRequest`-style executor contract).
- Buyers: small/mid hospitals.
- This is where the platform's genuinely missing pieces live (hoteling 0–1/10) — deliberately last.

---

## 3. How ONE platform serves all four tiers

1. **One patient identity.** Decision 1 (approved, "not to be reopened"): upgrade `lab_patients` in place to the shared patient entity — it already carries MRN, per-company unique national ID, insurance, portal links, and `partner_id` → business partner with auto AR/AP ledger accounts. Every tier reads/writes the same record; B2B lab patients are fenced by `external_lab_id IS NULL` scoping + guard tests.
2. **One financial spine.** Journals, safes, cashier shifts, insurance, NPHIES — scored 9/10 "battle-tested". Folio rule (Decision 4): lab invoices enter the folio **by reference, never re-posted** — single posting source per line. The unified charge-posting service (generalization register) prevents "the 6th copy" of receivable-account selection logic.
3. **One service-execution contract.** `CreateLabRequest` action + nullable `encounter_id` on lab requests (Phase 0 items): reception, an OBGY pregnancy sheet, or an inpatient ward all *order*; LIS/radiology *execute* and report back via events. The OBGY blueprint plugs into exactly this: `LabOrderPlaced` → LIS order via mapping table `obgy_lis_test_map` (legacy `invests` catalog: 276 tests, 22 categories → mapped/created in LIS); `LabResultReceived` lands results inside clinical sheets (blueprint §2.2).
4. **One pharmacy/inventory.** Blueprint §2.3: `PrescriptionDispensed` event → ERP inventory issue + sale line; drug catalog (~2,000 legacy items) mastered in the ERP item master; OBGY keeps only prescribing metadata.
5. **One frontend shell.** App-in-app pattern proven 3× (POS/HR/Lab) — HIS is the 4th, OBGY the 5th (hms report §7 UI row 8/10).
6. **The licensing prerequisite (must-fix).** `system.enabled_modules` is enforced **frontend-only** (`moduleGuard` in `auth.guard.ts:162`); the server never checks it — a "disabled" module's API remains callable, and the central licensing layer exists but is not wired as middleware (hms report §2). **You cannot sell differentially priced tiers until API-level enforcement ships.** It is already a Phase 0 item, in log-only mode first (measured reality: existing company configs are stale — immediate enforcement would break live flows).

---

## 4. Competitive differentiation — Egypt / Saudi

Capability claims below are file-backed; competitive positioning statements are **(inference)**.

| Differentiator | Backing |
|---|---|
| **NPHIES-ready in production, not on a roadmap** — FHIR eligibility/approvals/claims live in LIS today; extending to HIS items is a planned generalization, not a build | hms report §3 row "التأمين والمطالبات + NPHIES" (grade: جاهز); FHIR Patient built from `lab_patients` (Decision 1 note) |
| **Arabic-first clinical vocabularies harvested from OBGY** — ~190 legacy lookup tables (diagnoses, complaints, menstrual/local-exam terms, IVF protocols, TVS/HSG/endoscopy term dictionaries) consolidate into `obgy_lookups (domain, parent_id, title_ar, title_en, …)`, seeded from production data = years of real Arabic clinical usage | blueprint §1 consolidation table; §1.6, §1.10, §1.11. Hardest thing to buy off-the-shelf **(inference)** |
| **Full IVF/ICSI/IUI depth** — cycle entity with partial unique index (one active cycle/patient), follicle grid replacing 26 cryptic columns, embryo-transfer/cryo stages | blueprint §1.8. Rare in generic HIS products **(inference)** |
| **ERP-grade finance inside the medical system** — per-line real-time journal entries, patient-as-business-partner ledgers, FIFO payment allocation; the classic weak spot of clinic-software competitors **(inference)**, our documented 9/10 strength | hms report §7 row 1 |
| **Existing B2B lab network** — reference-lab portal with live customers = natural cross-sell channel into Tiers 2–4 | decision-1 B2B analysis |
| **Migration story as a sales weapon** — clinics on legacy PHP systems have a forced-move security motive (SQLi, open APIs, web-root DB dumps are typical of that generation); our P0–P7 idempotent-ETL playbook with risk register is itself a billable service **(inference on market; playbook is real)** | obgy-erp-analysis.md §5, §95 phases & risks |

---

## 5. Packaging → architecture: why OBGY must be a plugin on a HIS core, not the HIS core

The board question is whether OBGY becomes the core of HIS. The packaging analysis answers **no**, on four grounds:

1. **Price/feature separability.** A general hospital must not pay for (or carry) 85 OB/GYN specialty tables; an IVF center must not pay for ADT/beds. Toggleable licensing requires the specialty content isolated in `Modules/Obgy` behind a license key. OBGY-as-core destroys the tier matrix.
2. **OBGY lacks the HIS core itself.** Zero inpatient/beds/ADT, no insurance/NPHIES, finance done via magic codes in `visits.detectionid` (-99 installment / 999 settle / 9999 refund) + `totalbalance` — explicitly replaced, not ported (blueprint §1.2, §2.4). It cannot anchor a general hospital product.
3. **The OBGY blueprint already assumes this split.** Blueprint §2.6: `Encounter`, `OperativeNote`, `SurgicalBooking`, `Hospital`, `incision_types`, and the waiting-queue service are "designed module-agnostic so the HMS module can consume them."
4. **LIS standalone sale is protected** only if dependency direction stays HIS→LIS, never reverse (Decision 2). Same logic applies one level up: Clinic tier must not depend on Obgy.

**But OBGY meaningfully de-risks the HIS core** — this is the nuance the board should hear:

| OBGY blueprint capability | Lands in | Why |
|---|---|---|
| `Appointment` / `Encounter` / `VisitPeriod` / `ClinicClosure` / queue service (heir of `visits`, `visit_periods`, `vacations`, `detections` service catalog; mobile booking source enum) | **HIS core** | The platform's biggest gap (appointments 1/10) gets a domain design distilled from a system that ran real queues, day-period capacity limits, and mobile bookings for a decade **(architectural inference, supported by blueprint §1.2 and §2.6)** |
| `visit_prescriptions` / `visit_investigations` (morph-based prescription + order headers replacing 10+8 legacy clone tables) | **HIS core** | Generic clinical primitives any future specialty (cardio, dental, derma) reuses **(inference)** |
| Specialty sheets: `Pregnancy`, `GynaSheet`, `InfertilityFile`, `IvfCycle`, `SemenAnalysis`, `ImagingStudy`, `EndoscopyProcedure`, `OperativeNote` | **`Modules/Obgy` plugin** | Separately priced Tier-3 content, license-toggled |
| Legacy visit-money coupling (`PatientLedgerEntry` derivation, cURL sell-bill sync) | **Not built at all** | Replaced by HIS folio + existing accounting events (`VisitInvoiced` / `PaymentReceived` / `RefundIssued`, blueprint §2.4); single posting source per line (Decision 4) |

This also keeps EMR scope-creep risk (hms report risk #7) contained: HIS v1 stays administrative-financial; deep clinical documentation arrives only inside the priced specialty plugin where a paying segment funds it.

---

## 6. Rollout sequencing — who funds what

| Step | What ships | Who pays |
|---|---|---|
| **Now** | Phase 0 readiness package (~7–10 dev-days incl. permission-dependency registry): `CreateLabRequest` extraction, `encounter_id`, B2B hardening (8 items), branch scope to Core, module-key enforcement in log-only mode | Existing Tier-1 (lab) revenue. Non-negotiable licensing prerequisite for all tier sales |
| **Next 2 quarters** | HIS Phase 1 (outpatient) → launch **Moon Clinic** | Lab revenue + first clinic customers |
| **Parallel → capstone** | `Modules/Obgy` P1–P4 → launch **Moon Women's Health**. The legacy OBGY clinic is the reference customer: it has a forced security motive to migrate (SQLi, open `mobileservices.php`, web-root dumps — obgy-erp-analysis.md §7 lists 3 immediate-remediation items), and its production DB is the ETL rehearsal target (blueprint requires fresh production exports — risk R7). Migration services themselves are billable **(inference)** | OBGY clinic engagement + women's-health segment |
| **After Tiers 2–3 prove** | HIS Phase 2 (inpatient: beds/ADT/deposits/nightly charges) → launch **Moon Hospital**; Phase 3 extensions per market demand, item by item | Tier 2+3 revenue funds the most expensive net-new build |

Sequencing logic mirrors both source roadmaps: HIS report's phased plan (outpatient before inpatient) and the OBGY blueprint's P0–P7 ("each phase ships behind module permissions; legacy stays read-only reference until P7 sign-off").

---

## 7. Bottom line for the board

- **Sell one platform with four entry doors**: Lab (today) → Clinic (HIS Phase 1) → Women's Health (Clinic + Obgy plugin) → Hospital (HIS Phase 2/3).
- **OBGY is not the HIS core.** It decomposes: its generic scheduling/encounter/prescription patterns inform the HIS core (filling the platform's worst gap), while its 85-table specialty depth becomes the license-keyed `Modules/Obgy` — the strongest differentiation asset in the line, and the one no generic competitor can copy quickly because its value is a decade of Arabic clinical vocabulary and OB/GYN workflow, not code **(inference)**.
- **Two hard gates before any tier marketing**: server-side module/license enforcement (today frontend-only), and the Phase 0 contract work (`CreateLabRequest` + `encounter_id`) that makes "one platform" literally true.