# Phase 1 — Legacy Laboratory Software Audit

**Source:** PathCare Solutions v1.1.29 (TECHTROJAN) — `Pathcare.db`, `Setting.db`, 30 RDLC report templates, configuration.
**Date:** 4 August 2026
**Status:** Complete. Awaiting technical-lead approval before Phase 2.

Evidence marked **[verified]** was demonstrated by a query or by parsing the file
named. Nothing in this document interprets, corrects or approves a clinical
value; every such item is deferred to the pathologist.

---

## 1. What the source actually contains

| Item | Finding |
|---|---|
| Application | .NET Framework 4.6 WinForms, SQLite via Entity Framework, Microsoft ReportViewer |
| Databases | `Pathcare.db` (master data), `Setting.db` (device/SMS/WhatsApp settings) |
| Patient data | **None.** Every patient and result table is empty **[verified]** |
| Organisation | Single organisation, `HOID = 7` throughout **[verified]** |
| Collection centres | 7 rows in `CCenters` — the branch equivalent |
| Cloud | `Reports/urls.json` lists four failover API hosts, fetched from a third-party installer host |

The absence of patient data is significant and favourable: the migration scope
is the **test catalogue only**. There is no patient history to move and no
personal health information in this handover.

---

## 2. The clinical master

905 tests across 12 working departments. Nine further departments (XRAY, CT,
MRI, USG, ECG, Endoscopy, Audiometry, Spirometry, Medical Examination) are
declared but hold **zero** tests — this is a pathology laboratory only.

| Department | Tests | | Department | Tests |
|---|---|---|---|---|
| Microbiology | 280 | | Tumour Markers | 41 |
| Bio Chemistry | 198 | | Virology | 35 |
| Immunology | 106 | | Histopathology | 21 |
| Haematology | 95 | | Serology | 20 |
| Clinical Pathology | 52 | | Blood Bank | 7 |
| Endocrinology | 45 | | Radiology | 5 |

### How a result is structured

The legacy schema records results three ways, and **a count of "tests with no
parameters" badly misrepresents the catalogue** — most such tests are working
single-analyte tests that carry their range directly.

| Shape | Tests | Reading |
|---|---|---|
| Range attached directly to the test | 758 | Single-analyte test. Normal and correct. |
| Parameters + ranges (the CBC shape) | 36 | Multi-analyte panel; 293 parameter rows total |
| Neither, but has selectable options | 0 | — |
| Nothing at all | 110 | Genuinely unusable as-is |

**785 of 895 active tests have a usable result structure. 110 do not.** [verified]

The supplied workbook reports "No report parameters — 869", which counts the
758 healthy single-analyte tests as defects. That figure should not be used for
planning.

---

## 3. Critical finding — the critical limits are placeholders

Every one of the 2,033 reference ranges carries a critical low and high, which
would ordinarily be excellent. The stored values are not clinical thresholds:

| Critical low | Critical high | Rows |
|---|---|---|
| 0 | 2,000 | 1,103 |
| 0 | 99,999,999 | 606 |
| 0 | 99,999 | 134 |
| 0 | 9,999,999 | 56 |
| 0 | 999,999 | 32 |

These are sentinel values meaning "no limit set" **[verified]**. Only a handful
of rows carry anything resembling a real threshold.

**Migration rule (non-negotiable): critical limits are imported as NULL, never
copied.** Importing them produces a system that appears to monitor for critical
results and silently never raises one — the most dangerous possible outcome,
because the failure is invisible and the safety feature is trusted. A system
that honestly reports "no critical limit configured" is strictly safer.

Every critical limit must be entered fresh under pathologist approval.

---

## 4. Data quality (counts only — no corrections proposed)

| Issue | Count | Note |
|---|---|---|
| Ranges with no unit | 1,364 of 2,033 | Pathologist decision |
| Ranges numerically blank | 915 | Pathologist decision |
| Tests with no usable code | **810** of 905 | 427 blank, 347 zero, 36 null **[verified]** |
| Genuinely duplicate active code | **1** (`556`) | Workbook reported 2 |
| Orphan parameters | 1 | |
| Orphan ranges | 0 | |
| Reversed ranges (low > high) | 0 | |

The missing test codes are worse than the workbook reported (810 vs 463) but are
an administrative problem, not a clinical one — codes can be generated. The
missing units and ranges are clinical and cannot.

`test_attribute.insert_type` does **not** hold a result entry type despite its
name. Its non-empty values are report section headings — "Gross Examination",
"Microscopic Examination", "Physical Examination" **[verified]**. The workbook's
"Missing result entry type — 226" is therefore mislabelled; the field never held
that meaning.

---

## 5. The report contract — seven result shapes

All 14 result templates (branch variants 1–6 and Provisional × Header/Simple)
are structurally **identical**: 133 fields, 14 parameters, 7 datasets
**[verified]**. They differ only in layout; the Provisional template differs
from variant 5 by the column spacing of a single label.

The seven datasets are the seven shapes a printed result can take:

| Dataset | Shape | Key fields |
|---|---|---|
| `GeneralResultReport` | Numeric / text with range | `AttributeName, Result, Range, Units, Bold, ReasonBold, DisplayOrder`, previous **two** visits with times |
| `MicroResults` | Culture & sensitivity | `Organism, Drug, Sensitivity, Culture, Specimen` — key printed as **(S)ensitive, (R)esistant, (I)ntermediate** |
| `pcrResultReport` | PCR / viral load | `Value, Result`, control images, prints "VIRAL LOAD" |
| `elisaResultReport` | ELISA | `Value, Cuttoff, Range` |
| `cytoResultReport` | Histopathology / cytology | `Grossex, Microex, Clinical, Note` — narrative sections |
| `WResult` | Widal serology titre grid | **36 hard-coded columns**: 6 antigens × titres 1:20…1:640 |
| `patient_info` | Demographics + billing | 54 fields, see below |

### What a printed report carries

- **Patient** — name, guardian, age + age type, sex, CNIC, phone, email,
  address, WhatsApp number, MR number, Case ID, patient note
- **Registration** — reg number, entry date/time, registration place
  (collection centre), ward, priority, consultant / referring doctor
- **Specimen** — specimen type, sample received flag and time
- **Trail** — entered by + timestamp, approved by + timestamp
- **Signatures** — up to **four** doctors, each with a qualification line
- **Verification** — **two** QR codes, online and offline
- **Provisional** — a note passed in at print time
- **Billing** — total, discount, discounted by, receivable, paid, balance,
  referrer share, lab amount

---

## 6. Legacy weaknesses — do not reproduce

1. **Fourteen copies of one 450 KB template.** A wording change means fourteen
   edits, and they have already drifted (one label's spacing differs). The new
   system needs one template with branch-level variation as data.
2. **The Widal test is hard-coded into the report** — 36 named columns for one
   test. Any second titre-based test requires a code change. This belongs as a
   general "titre grid" result type.
3. **Signatures arrive as print-time parameters, not stored data.** Who signed a
   given report is therefore not recoverable afterwards. Clinic's requirement
   that an authorised report snapshot be immutable and attributable is
   incompatible with this and must replace it.
4. **Billing figures print on a clinical report.** A deliberate product decision
   is needed; it is not automatically correct.
5. **Credentials in the distributed database.** `operators.password` (10 staff)
   and `ref_by.UserName`/`Password` (1,002 referring doctors) **[verified,
   values not read]**. These must not be migrated. Referrer logins belong in the
   normal user system if that capability is wanted at all.

---

## 7. Fit against the existing Clinic Laboratory module

Clinic already implements: tests and panels, reference ranges with
most-specific-first matching, orders, specimens with collection and rejection,
result entry, amendment and retraction, critical-result events, external
results, printed report and request views, web UI, API, and tests. Its reference
range model is **stronger** than the legacy one — age in days rather than whole
years, and documented matching precedence.

Gaps requiring new work:

| Gap | Size | Why |
|---|---|---|
| Microbiology culture & sensitivity | **Large** | Organism + antibiotic grid with S/R/I; 174 organisms, 110 drugs; largest department |
| Custom result option lists | Medium | 478 rows; `ResultType` today is fixed `positive_negative` and cannot express "Repeat With Fresh Sample" |
| Narrative sections (gross / microscopic / clinical) | Medium | Histopathology and cytology |
| PCR and ELISA cutoff results | Medium | `Value` + `Cuttoff` has no equivalent |
| Titre grid result type | Medium | Replaces the hard-coded Widal columns |
| Multiple signatories on a report | Small | Up to four, with qualifications, stored not passed |
| Second (offline) QR code | Small | |
| Outsourced tests | Small | Only 6 tests |

**This is larger than the two gaps estimated before the templates were read.**
Five specialised result types are required, not one.

---

## 8. Unresolved — for the next phase

1. Are all seven result shapes in scope for first release, or is a subset
   (General + Microbiology) enough to go live?
2. Should billing figures appear on the clinical report?
3. Do referring doctors need portal logins, or is that capability dropped?
4. Which of the 7 collection centres map to which Clinic branches?
5. The 110 tests with no result structure — build, or retire?

## 9. Phase 1 completion checklist

- [x] Full source inventory, databases, reports, configuration
- [x] Schema catalogue with row counts
- [x] Report catalogue: 30 templates, contract extracted
- [x] Data-quality counts, no values altered
- [x] Risk register
- [x] Fit assessment against the existing module
- [ ] Technical-lead approval → Phase 2