ZM Zainab Mohammed
← All work

Case study 05 · Hospital

HMSHospital Management System

Clinical and operational software covering every department of an inpatient hospital, from the front desk to discharge, with safety checks built into the workflow itself.

Role
Solution architect & lead engineer
Client
Private hospital, Kurdistan Region of Iraq
Status
Going live
Stack
Go · PostgreSQL · Lit · FHIR R5 · CDS Hooks
01

The problem

Private hospitals in the region often manage patients across separate tools and paper, each with its own patient list and its own prices, so departments rarely agree on who the patient is or what they owe.

HMS replaces that with a single record. A patient registered once moves through reception, clinics, the emergency department, wards and theatre, and every chargeable event reaches the same bill.

02

At a glance

12
hospital staff roles
11
admission types, each with its own policy
27
registration fields, configurable per type
36,683
coded diagnoses (28,157 with ICD-10)
03

What it covers

Patient access & flow

reception · clinics · ED · wards

  • Reception: registry search across name, MRN, phone and national ID; Arabic four-part names; duplicate guard and patient merge; a 3-step admit wizard.
  • 11 admission types, each with its own policy on deposits, prior authorisation, rooms and specialties. 27 registration fields can each be set to required, optional or hidden per type.
  • Outpatient clinics: a live queue model (patients hold a place in line, not a time slot) with 10 queue states, a two-step call-in and return-after-results ordering.
  • Emergency department: triage board, re-triage history kept as a record of deterioration, full dispositions, and door-to-triage and length-of-stay reported as median and 90th percentile.
  • Wards: atomic bed claims so two nurses cannot book the last bed twice; a raise → accept → complete transfer handshake with an escalation service that survives restarts.

Clinical record & critical care

EMR · scores · ICU · maternity

  • EMR: ICD-10 conditions, allergies, LOINC-coded vitals with automatic interpretation, consents, code status, isolation signage, care plans, SBAR handoff and a patient-journey timeline.
  • Risk scores: NEWS2, Morse, Braden, SOFA, qSOFA and APACHE II, computed on the server so they can be reproduced. Missing values are never silently scored as zero.
  • ICU: ventilator episodes, with ventilator-days computed rather than stored.
  • Maternity: labour partogram with WHO alert and action lines, postpartum haemorrhage monitoring, newborns as separate patients with automatic NICU routing below 37 weeks, WHO 2006 and INTERGROWTH-21st growth curves, and a human milk bank.

Theatre & blood bank

safety gates in the workflow

  • Theatre: the WHO Surgical Safety Checklist acts as a gate: surgery cannot start until sign-in and time-out are complete. Also implant recall tracking, and a team roster that drives the fee split.
  • Blood bank: donor deferral, quarantine until screening clears, lookback investigation, and crossmatch as a gate before transfusion.

Care pathways

orchestration · decision support

  • FHIR-based workflow orchestrator that turns a care pathway into dependent tasks and escalates them when overdue. It ships with the Surviving Sepsis one-hour bundle.
  • CDS Hooks engine, order sets and questionnaires.
  • Shared department kiosk: ED, ICU, maternity, theatre and wards share the same tabs (stock locker, reports, front desk, shifts), and the server works out the user's department from their login.
04

Architecture

  • On-premises deployment. One Go executable serves the API and the embedded web app, so the hospital runs it on its own network with no internet needed. Build, run, migration and backup scripts are included.
  • Data. Schema bootstrap and seeding are safe to re-run at every start. Clinical catalogues are compiled into the binary and upserted by their source concept id.
  • Frontend. Lit 3 web components built with Vite. One design system and CSS logical properties let a single stylesheet serve both reading directions.
05

One patient, one record

  • One patient identity across reception, clinics, ED, wards, theatre and billing, with a unified history and a FHIR $everything export.
  • One security model: role-based access checked on every API call, department scoping, account lockout, forced password rotation, instant session revocation, and an audit trail that records before and after values.
  • One setup console replacing about 18 settings screens, plus a specialty configuration engine: 12 kinds of clinical content in mandatory, common and quick sets, inherited down the specialty tree. A child specialty can never weaken what its parent requires.
  • Safe concurrency: an atomic claim on disposal of a case (the losing request gets a 409 instead of creating a duplicate) and one close-out routine for every admission.
  • Arabic / English: full right-to-left layout from one stylesheet; translations stored as locale-keyed JSONB with fallback. Screen text is translated; clinical free text never is.
  • Clinical terminology: I converted the 58,829-concept CIEL dictionary from MySQL to PostgreSQL through a Python ETL pipeline. SNOMED CT, ICD-10/11, RxNorm and LOINC codes come in through CIEL's crosswalks; search runs on pg_trgm indexes.
  • Reporting: an on-screen report designer with 9 block types, JsonLogic rules and versioned publishing to HTML and PDF. Notifications can target a department, role or user.
06

Engineering approach

  • Values that change are computed on read, not stored. Overdue doses, ventilator-days, ward rounds and OR occupancy can never drift out of date, and no clean-up job is needed.
  • Atomic claims for concurrent actions. When two staff members race for the same bed or disposition, the second is told cleanly that someone else got there first.
  • Clinical records are immutable. Reports, prices and results get new versions; old rows are never edited.
  • Side effects never block care: notifications, billing and audit logging fail safely.
  • Large-scale restructuring. The backend began as one flat handlers package with 1,572 route registrations in a single main.go. Over 30 planned batches I split it into 49 domain packages, measured the package graph and removed the shims, with no change to any endpoint's behaviour or security.
  • Quality engineering. 750+ Go tests (81 against real PostgreSQL) and 43 Playwright suites. Over 140 defects tracked in a numbered register and closed only after verification.
  • Documentation: 300+ engineering documents, plus bilingual sales material generated from a single content source.
07

Results

  • One record from reception to discharge, with one bill per patient.
  • Safety barriers built into the workflow rather than added as reports: surgical checklist, crossmatch and escalating care pathways.
  • Fitted to the regional market: Arabic RTL and fully on-premises.
  • Going live with a 4-wave implementation plan, starting with the revenue areas.

Roadmap

  • Two-factor login
  • Live push updates
  • Bedside barcode scanning
  • Offline & mobile
  • Multi-hospital groups
  • Analytics warehouse
  • Kurdish interface
—

More work

← RIS Next: Pharmacy