# 07 — Target HIS Scope (Any Hospital): Canonical Capability Definition & Sourcing Matrix

Author scope: hospital-information-systems domain analysis for the Moon ERP board decision
(ERP ↔ LIS ↔ HIS ↔ OBGY). Source of all OBGY claims:
`/home/amrtechogate/public_html/obgy-erp-analysis.md` (sections 02 Visits, 10 Operations,
13 Follow-up, 95 Migration Blueprint, plus 11 Examination, 14 Investigations, 15 Pharmacy,
16 Financial, 18 Platform headings). Moon ERP coverage statements (Accounting, Inventory,
HRM, LIS, NPHIES) are taken as given per the study brief (the ERP codebase is not present
in this environment) and are marked **[brief assumption]**.

---

## 1. Method and naming convention

Capability names are aligned with FHIR R4 resources because the existing OBGY analysis
already uses FHIR-shaped target models (`Appointment`, `Encounter`, `EpisodeOfCare`
mentioned for `endvisitreports`, prescription → `MedicationRequest` semantics,
`LabOrder` → `ServiceRequest`/`DiagnosticReport`, `Procedure`, `ImagingStudy`).
Evidence: blueprint §1.2 ("`Appointment` | `visits` (booking half)", "`Encounter` |
`visits` (queue half) + `followupcard`"), §2.2 LIS events `LabOrderPlaced` /
`LabResultReceived`, §2.3 `PrescriptionDispensed`, §2.4 `VisitInvoiced` /
`PaymentReceived` / `RefundIssued` — all in
`/home/amrtechogate/public_html/obgy-erp-analysis.md` (section "95 — ERP Migration Blueprint").

Sourcing classes used in the matrix:

- **ERP** — capability already exists in Moon ERP modules (Accounting / Inventory / HRM /
  LIS / NPHIES) **[brief assumption]**.
- **OBGY-seed** — the OBGY analysis produced a concrete, validated target design
  (tables, models, events) that can seed the HIS build. Note the hard rule in the
  blueprint risk register (R12): *"no legacy endpoint ported"* — seeds are **data-model
  and workflow designs**, never legacy PHP code (SQL injection confirmed system-wide,
  section 00 §5.1; unauthenticated mobile API, section 02).
- **Net-new** — nothing usable exists; must be designed and built from scratch.

---

## 2. Canonical HIS capability matrix

| # | Capability | FHIR alignment | Exists in Moon ERP | Seeded by OBGY analysis | Net-new build | v1 priority |
|---|------------|----------------|--------------------|--------------------------|---------------|-------------|
| 1 | **MPI — Master Patient Index** | `Patient`, `Person`, identifiers | Partial — ERP patient/client master exists; blueprint §1.1: "The legacy patient **becomes** the ERP patient/client" **[brief assumption + blueprint]** | Yes — dedup requirements traced (risk R10: MAX+1 file numbers, duplicate national IDs, drafts `done=0`); profile-split pattern `obgy_patient_profiles` | Merge/duplicate-review workflow, per-facility MRN issuance, identifier domains | **P0 Critical** |
| 2 | **Appointments & Scheduling** | `Appointment`, `Schedule`, `Slot` | No | **Strong** — `visits` (booking half), `visit_periods` (capacity `max_no`), waiting list (`urgent=1`), mobile booking (`mobileservices.php` workflows), `vacations` → `ClinicClosure`; target models `Appointment`, `VisitPeriod` (§1.2) | Multi-resource scheduling (practitioner + room + equipment), recurring schedules | **P0 Critical** |
| 3 | **OPD clinics & outpatient Encounter** | `Encounter` (ambulatory), `EpisodeOfCare` | No | **Strong** — `Encounter` model from `visits` queue half + `followupcard` (§1.2); queue mechanics `visitorder`/`enterordered`/`view`, sheet routing `lastvisit`, waiting-screen `screen_slider` + "queue websocket feed" (§1.16); `endvisitreports` → `TreatmentClosure` (analysis suggests modeling "as status on an EpisodeOfCare", section 02) | Multi-specialty clinic configuration, generic department model | **P0 Critical** |
| 4 | **ADT — Admission / Discharge / Transfer** | `Encounter` (inpatient), `EpisodeOfCare`, `Location` | No | Faint only — `Hospital` (`hospitalnames`) catalog, transfer letters (`instruction.php::printtransfer`, print-only, no persistence); `branches`/`floors`/`devices`/`device_tracking` exist but were an **incomplete feature, explicitly dropped** with "keep schema design note for HMS" (§1.16) | **Yes — entire admission lifecycle**: admit orders, transfer, discharge summary, LOS, EpisodeOfCare state machine | **P0 Critical** |
| 5 | **Bed & Ward Management** | `Location` (ward/room/bed tree), `Encounter.location` | No | No (the `floors`/`devices` tables are not a bed model) | **Yes** — location hierarchy, bed states (occupied/reserved/cleaning), census board | **P0 Critical** |
| 6 | **Emergency Room (ER)** | `Encounter` (emergency), triage `Observation` | No | Faint — urgent waiting list (`urgent=1`, section 02) is a priority flag, not triage (استنتاج/inference) | **Yes** — triage scales (CTAS/ESI), ER tracking board, disposition | **P1 High** (v1.5 acceptable) |
| 7 | **CPOE — unified orders (lab/rad/pharmacy/procedure)** | `ServiceRequest`, `MedicationRequest` | Lab execution side exists (LIS) **[brief assumption]** | **Strong shape** — blueprint consolidations: 8 `*invest` clones → `LabOrder`/`LabOrderItem` (morphs `orderable`); 10 `*drugs` clones → `Prescription`/`PrescriptionItem` (morphs `prescribable`); `op_wait_list` → `SurgicalBooking`; events `LabOrderPlaced`, `LabResultReceived`, `PrescriptionDispensed` (§2.2, §2.3) | Unified order hub (one `ServiceRequest` spine), radiology orders, order sets, order status lifecycle | **P0 Critical** |
| 8 | **Clinical Documentation (notes/forms)** | `Condition`, `Observation`, `QuestionnaireResponse`, `DocumentReference` | No | **Strong** — `ClinicalExamination` (vitals, section 11), configurable Q&A engine `presenthistoryquestions`/`presenthistoryanswers` → `HistoryQuestion`/`HistoryAnswerOption`/`PatientHistoryAnswer` (§1.3), `ClinicalNote` with `note_type` enum (merge of `followupdiagnosis`+`followupexam`+`followupinvest`, section 13), `Diagnosis` + `encounter_diagnoses` pivot | Generic form-builder for any specialty, ICD-10/SNOMED coding, sign-off/amend workflow | **P0 Critical** |
| 9 | **eMAR & Inpatient Pharmacy** | `MedicationRequest`, `MedicationDispense`, `MedicationAdministration` | Stock/item master exists (Inventory) **[brief assumption]**; blueprint §1.14: "drug catalog and stock delegate to ERP inventory item master; the module keeps only the prescription layer" | Partial — outpatient dispense chain (`recepittmp`/`receiptdrugs` → `PrescriptionDispensed` event, §2.3); intra-op drugs (`operativedetailsdrugs`, section 10) | **Yes — administration layer**: scheduled doses, nurse administration record, ward stock, IV management | **P0 Critical** (minimal eMAR in v1) |
| 10 | **OR Management** | `Procedure`, `ServiceRequest`, `Encounter` | No | **Strong** — `SurgicalBooking` (`op_wait_list`), `OperativeNote` (`operativedetails`) with `operative_note_staff` pivot (anesthetist/assistant teams), `AnesthesiaType` cascade (`anasthesa`→`generalanasthesa`), `incision_types` (`jncision`/`midlinejncision`), `PathologyResult` (`pathology`), intra-op drug grid wired to pharmacy (section 10); §2.6: these are "designed module-agnostic so the HMS module can consume them" | OR room/slot scheduling board, pre-op checklist (WHO SSC), PACU/recovery, sterilization link | **P1 High** |
| 11 | **Nursing Station** | `Observation` (vitals), `Task`, `CarePlan` | No | Faint — vitals fields in `examination` (section 11); queue/waiting-screen service (§1.16) (استنتاج for reuse) | **Yes** — nursing assessments, care plans, task lists, shift handover, fluid balance | **P1 High** |
| 12 | **Billing / Patient Folio + Insurance cycle** | `Account`, `ChargeItem`, `Invoice`, `Claim`, `Coverage` | **Yes (backbone)** — Accounting + NPHIES (Saudi insurance) **[brief assumption]** | **Strong bridge** — `PatientLedgerEntry` (from `totalbalance` + magic `detectionid` -99/999/9999 codes), `Invoice`/`Payment` via events `VisitInvoiced`/`PaymentReceived`/`RefundIssued` (§2.4), `Service` price catalog (`detections`) | Inpatient folio (charge accumulation per admission from CPOE/eMAR/OR), package pricing, pre-authorization workflow per encounter | **P0 Critical** |
| 13 | **Lab orders → LIS** | `ServiceRequest`, `DiagnosticReport` | **Yes** — mature LIS module in production **[brief assumption]** | Yes — catalog mapping layer `obgy_lis_test_map`; `LabOrderPlaced` → LIS order, LIS publishes `LabResultReceived` → result on `lab_order_items` (§2.2, §1.13: `investcats` 22 categories, `invests` 276 tests) | Thin — HIS just consumes the same contract | **P0 Critical (reuse)** |
| 14 | **Radiology (RIS/PACS)** | `ImagingStudy`, `ServiceRequest`, `DiagnosticReport` | No | Partial — `ImagingStudy` unified report header design (section 08/§1.10: `ultrasound*`, `tvs`, `hsg`, `mrict`, `sonar` media), structured findings + `MediaAttachment` | **Yes** — modality worklist, DICOM/PACS integration, radiologist reporting queue | **P2 Medium** (reporting-only in v1) |

### Matrix totals

- 14 canonical capabilities.
- **4** materially covered by Moon ERP backbone (MPI partial, billing backbone, LIS, pharmacy stock) **[brief assumption]**.
- **7** meaningfully seeded by OBGY's analyzed target designs (scheduling, OPD encounter/queue, CPOE shape, clinical documentation, OR, billing bridge, lab-order UX).
- **5** are net-new HIS core with no OBGY precedent: **ADT, beds/wards, ER, eMAR administration layer, nursing station** — i.e. the entire *inpatient* spine.

---

## 3. What the OBGY analysis actually contributes (and what it does not)

### 3.1 Reusable, module-agnostic seeds (explicit in blueprint §2.6)

> "HMS (planned): `Encounter`, `OperativeNote`, `SurgicalBooking`, `Hospital`,
> `incision_types`, and the waiting-queue service are designed module-agnostic so the
> HMS module can consume them."
> — `/home/amrtechogate/public_html/obgy-erp-analysis.md`, §2 Integration Contracts, row 2.6

Concrete seeds with file-traceable evidence:

1. **Appointment/Encounter split** — section 02 ERP Migration Notes propose `Appointment`
   (status enum booked/arrived/in_consultation/done/cancelled), queue position, and
   `PaymentTransaction` that "eliminates magic detectionid -99/999/9999".
2. **Encounter-linkage repair** — risk R2: legacy clinical rows "never reference visits";
   the new design makes `encounter_id` mandatory on clinical records — exactly the HIS-grade
   discipline a general hospital needs.
3. **CPOE consolidation patterns** — §1 cross-cutting table: 10 `*drugs` tables →
   `visit_prescriptions` + `prescription_items`; 8 `*invest` tables →
   `visit_investigations` + `lab_order_items` with polymorphic `orderable`/`prescribable`.
   This is a ready blueprint for `MedicationRequest`/`ServiceRequest` semantics.
4. **Surgical lifecycle** — section 10: booking (`op_wait_list`), operative note
   (`operativedetails` 25+ structured fields), team pivot, anesthesia cascade, intra-op
   pharmacy integration, histopathology/pathology results.
5. **Patient ledger** — section 16 `totalbalance`/`totalbalancepaids` + section 02 magic
   codes → typed `PatientLedgerEntry` (charge/payment/refund/package_credit/installment),
   posting to ERP accounting via events (§2.4).
6. **Configurable history/forms engine** — `presenthistoryquestions`/`presenthistoryanswers`
   (section 11) is a primitive `Questionnaire`/`QuestionnaireResponse` — a seed for the HIS
   clinical-forms builder (استنتاج: generalization is ours, the seed is theirs).

### 3.2 What OBGY does NOT provide (net-new HIS core)

- **No admission concept**: every encounter is same-day ambulatory; `visits.view` 0/1 is
  waiting/entered, not admitted (section 02).
- **No beds**: `floors`/`devices`/`device_tracking` were "incomplete feature" and the
  blueprint **drops** them (§1.16) keeping only a "schema design note for HMS".
- **No ER/triage**, **no nursing documentation**, **no medication administration** —
  prescriptions end at dispense (`PrescriptionDispensed`), never at administration.
- **No insurance**: the legacy system is cash/visa only (`detectionvalue_cash`,
  `detectionvalue_visa`, section 02); the whole payer/claim cycle relies on Moon ERP NPHIES
  **[brief assumption]**.
- **Specialty bulk is not HIS**: ~9 of 19 analyzed modules (antenatal, gynecology,
  infertility, IVF, andrology, imaging-OB, endoscopy, history-OB, board) are OB/GYN-specific
  clinical content with no general-hospital reuse (استنتاج from module purposes).
- **Zero code reuse**: risk R12 hard rule — "no legacy endpoint ported"; SQL injection
  confirmed widespread (section 00 §5.1), generic table/column AJAX writers, unauthenticated
  mobile API. Seeds are designs and migrated data only.

---

## 4. Sellable v1 cut (priority rationale)

A hospital will not buy an HIS without the inpatient spine, even though OBGY contributes
nothing there. Recommended v1 line (استنتاج — product judgment on top of traced facts):

- **v1 (P0)**: MPI + Appointments + OPD Encounter/queue + ADT + Beds/Wards + CPOE
  (lab+pharmacy+procedure) + Clinical documentation + minimal eMAR + Billing folio/NPHIES
  bridge + LIS reuse. (Rows 1–5, 7–9, 12–13.)
- **v1.5 (P1)**: ER tracking/triage, OR management (fast-follow, strongly OBGY-seeded),
  nursing station.
- **v2 (P2)**: RIS/PACS radiology, full eMAR/IV, care plans.

Architecture corollary for the board (fact base for the separate verdict section): the
shared seeds (`Encounter`, CPOE shapes, ledger, queue service) belong in a **shared
clinical core** consumed by both HIS and a `Modules/Obgy` specialty module — exactly the
direction §2.6 of the blueprint already points to; OBGY as-is cannot be "the HIS core"
because the 5 inpatient capabilities and the insurance cycle are absent from it.

---

## 5. Source citations

- `/home/amrtechogate/public_html/obgy-erp-analysis.md` — section "Module: Visits & Appointments (visits)" (tables `visits`, `visit_periods`, `lastvisit`, `endvisitreports`, `vacations`; workflows 1–8; ERP Migration Notes).
- Same file — section "Module: Operations & Deliveries (operations)" (tables `operation`, `operations`, `operativedetails`, `operativedetailsdrugs`, `op_wait_list`, `anasthesa`, `generalanasthesa`, `hospitalnames`, `pathology`, `detections`; workflows 1–9).
- Same file — section "Module: Follow-up & Follow-up Cards (followup)" (tables `followup`, `followupcard`, `followupcarddrugs`, `followupvisit`, `instruction`; ghost table `followupdrugs`).
- Same file — section "95 — ERP Migration Blueprint" (§1 consolidation patterns, §1.2 Encounters/Billing bridge, §1.3 Clinical core, §1.13 LIS mapping, §1.14 Pharmacy, §1.16 Platform, §2 Integration contracts 2.1–2.6, §3 phases, §4 risk register R1–R12).
- Same file — section "00 — Technical Architecture Deep-Dive" §5.1 (SQLi confirmed) — basis for the no-code-reuse rule.
- Moon ERP module coverage (Accounting, Inventory, HRM, LIS, NPHIES): **study brief assumption**; ERP source not present under `/home/amrtechogate/public_html` (verified: directory contains only `obgy/`, analysis outputs, and work folders).