Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Task 11 — Healthcare and Hospital Management Network

Objective

Create a healthcare and hospital management system for a network of hospitals.

The system must manage:

  • hospitals
  • departments
  • wards
  • rooms
  • beds
  • patients
  • doctors
  • nurses
  • medical staff
  • appointments
  • emergency admissions
  • triage
  • hospital admissions
  • diagnoses
  • treatments
  • medications
  • medication orders
  • laboratory tests
  • medical procedures
  • surgeries
  • operating rooms
  • staff shifts
  • equipment
  • bed allocation
  • discharge
  • patient transfers
  • medical history
  • billing records
  • operational events
  • audit history

The implementation must coordinate both:

medical state

and:

hospital operational state

A patient may require treatment immediately while the hospital simultaneously has limited:

  • beds
  • doctors
  • nurses
  • operating rooms
  • equipment

The system must therefore manage priorities, schedules, resource conflicts, and patient history while preserving consistent state.

Hospital Network

Create a network containing at least three hospitals.

For example:

        H01 — Central General Hospital
        H02 — North Medical Center
        H03 — South Regional Hospital

Hospitals may have different:

  • departments
  • bed capacities
  • medical staff
  • equipment
  • operating rooms
  • specializations

Patients may be transferred between hospitals when the required resources are unavailable locally.

Hospital

A possible model is:

type Hospital struct {
    ID      string
    Name    string
    City    string
    Country string
}

Department

Each hospital contains departments. Examples:

  • Emergency
  • Cardiology
  • Neurology
  • Surgery
  • Orthopedics
  • Pediatrics
  • Internal Medicine
  • Intensive Care
  • Radiology
  • Laboratory

A possible model is:

type Department struct {
    ID         string
    HospitalID string
    Name       string
    Type       DepartmentType
}

Ward

Departments may contain wards.

type Ward struct {
    ID           string
    DepartmentID string
    Name         string
    Type         WardType
}

Possible ward types:

general
intensive_care
isolation
pediatric
postoperative

Room

A ward contains rooms.

type Room struct {
    ID     string
    WardID string
    Number string
    Status RoomStatus
}

Possible states:

available
occupied
cleaning
maintenance
closed

Bed

Beds are independently allocatable resources.

type Bed struct {
    ID     string
    RoomID string
    Status BedStatus
}

Possible states:

  • available
  • reserved
  • occupied
  • cleaning
  • maintenance
  • unavailable

A bed may belong to a valid room while still being unavailable independently.

Patient

A patient contains:

  • ID
  • First Name
  • Last Name
  • Date of Birth
  • Sex
  • Blood Type
  • Phone
  • Emergency Contact

For example:

type Patient struct {
    ID               string
    FirstName        string
    LastName         string
    DateOfBirth      time.Time
    Sex              string
    BloodType        string
    Phone            string
    EmergencyContact string
}

Medical Staff

Create a common staff model.

type MedicalStaff struct {
    ID           string
    HospitalID   string
    FirstName    string
    LastName     string
    Status       StaffStatus
}

Possible states:

  • available
  • working
  • off_shift
  • on_leave
  • unavailable

Doctor

Doctors contain additional information:

  • Specialization
  • Department
  • Qualifications

For example:

type Doctor struct {
    StaffID       string
    DepartmentID  string
    Specialization string
    Qualifications []string
}

Nurse

A nurse may contain:

type Nurse struct {
    StaffID      string
    DepartmentID string
    Skills       []string
}

Staff Shift

Staff availability must be represented explicitly.

type StaffShift struct {
    ID        string
    StaffID   string
    StartTime time.Time
    EndTime   time.Time
    Status    ShiftStatus
}

A staff member cannot be assigned to two operations during overlapping time intervals.

Appointment

Patients may schedule appointments.

type Appointment struct {
    ID           string
    PatientID    string
    DoctorID     string
    DepartmentID string
    StartTime    time.Time
    EndTime      time.Time
    Reason       string
    Status       AppointmentStatus
}

Possible states:

  • scheduled
  • confirmed
  • in_progress
  • completed
  • cancelled
  • no_show

Appointment Validation

A valid appointment requires:

  • patient exists
  • doctor exists
  • doctor belongs to appropriate department
  • doctor is working during requested interval
  • doctor has no conflicting appointment
  • start time < end time

Two active appointments for the same doctor may not overlap.

Emergency Department

Emergency patients may arrive without an appointment. Create an emergency case:

type EmergencyCase struct {
    ID          string
    PatientID   string
    HospitalID  string
    ArrivalTime time.Time
    Priority    TriagePriority
    Status      EmergencyStatus
}

Triage

Emergency patients must be prioritized. Use five priority levels:

        P1 — Immediate
        P2 — Very Urgent
        P3 — Urgent
        P4 — Standard
        P5 — Non-Urgent

Lower numeric value means higher priority. For patients with the same priority:

earlier arrival is processed first

If both are equal:

lower EmergencyCase ID is processed first

Emergency Queue

The queue must therefore be ordered by:

  • Priority
  • ArrivalTime
  • EmergencyCaseID

Example:

        E01 — P3 — 10:00
        E02 — P1 — 10:05
        E03 — P2 — 09:58
        E04 — P1 — 10:07

Processing order:

        E02
        E04
        E03
        E01

Emergency priority may override normal appointment scheduling when explicitly required by the scenario.

Emergency Preemption

Suppose:

Operating Room OR-01
Scheduled Surgery: 14:00

At:

13:20

a P1 emergency patient arrives and requires immediate surgery.

If no alternative operating room is available, the system may postpone the scheduled non-emergency procedure.

The operation must:

  • identify the conflict
  • preserve the original surgery
  • change its schedule explicitly
  • record the reason
  • allocate resources to the emergency case
  • generate operational events

The scheduled surgery must not silently disappear.

Admission

A patient may be admitted to the hospital.

type Admission struct {
    ID           string
    PatientID    string
    HospitalID   string
    DepartmentID string
    WardID       string
    BedID        string
    AdmittedAt   time.Time
    DischargedAt *time.Time
    Status       AdmissionStatus
}

Possible states:

  • requested
  • admitted
  • transferred
  • discharged
  • cancelled

Bed Allocation

Before admission:

  • appropriate ward must exist
  • bed must be available
  • bed must not already be reserved
  • bed must satisfy patient requirements

Examples of special requirements:

  • intensive care
  • isolation
  • pediatric ward
  • postoperative care

Atomic Bed Allocation

Admission and bed allocation should behave as one logical operation. The system must not produce:

Admission.Status = admitted

while leaving:

Bed.Status = available

for another patient. After successful admission:

Admission.Status = admitted
Bed.Status = occupied

Bed Capacity Scenario

Suppose ICU contains:

ICU-B01 — occupied
ICU-B02 — occupied
ICU-B03 — available

Two patients request ICU admission.

Only one may receive:

ICU-B03

The other patient must remain waiting or be considered for transfer.

Diagnosis

A patient may receive multiple diagnoses.

type Diagnosis struct {
    ID          string
    PatientID   string
    DoctorID    string
    Code        string
    Description string
    DiagnosedAt time.Time
}

Diagnoses form part of permanent medical history.

Treatment Plan

A diagnosis may result in a treatment plan.

type TreatmentPlan struct {
    ID          string
    PatientID   string
    DiagnosisID string
    DoctorID    string
    Status      TreatmentStatus
}

Possible states:

  • created
  • active
  • completed
  • cancelled

Medication

Create a medication catalog.

type Medication struct {
    ID       string
    Name     string
    Unit     string
    Stock    int
}

Medication Order

Doctors may prescribe medication.

type MedicationOrder struct {
    ID           string
    PatientID    string
    DoctorID     string
    MedicationID string
    Dose         string
    Frequency    string
    StartTime    time.Time
    EndTime      time.Time
    Status       MedicationOrderStatus
}

Medication orders must reference existing:

  • patient
  • doctor
  • medication

Medication Inventory

Hospital medication stock must not become negative. Dispensing medication should:

  • validate active order
  • validate stock
  • reduce stock
  • record administration

Medication Administration

type MedicationAdministration struct {
    ID                string
    MedicationOrderID string
    PatientID         string
    StaffID           string
    Timestamp         time.Time
    Quantity          int
}

Administration history must remain available after the treatment ends.

Laboratory Test

A doctor may request a laboratory test.

type LabTestOrder struct {
    ID          string
    PatientID   string
    DoctorID    string
    TestType    string
    Priority    TestPriority
    Status      LabTestStatus
    RequestedAt time.Time
}

Possible states:

  • requested
  • sample_collected
  • processing
  • completed
  • cancelled

Laboratory Result

type LabResult struct {
    ID        string
    TestID    string
    Values    map[string]string
    ResultAt  time.Time
    Reviewed  bool
}

Completed results become part of patient medical history.

Medical Equipment

Hospitals contain limited equipment. Examples:

  • MRI
  • CT Scanner
  • X-Ray
  • Ventilator
  • Ultrasound
  • ECG
  • Dialysis Machine

A possible model:

type MedicalEquipment struct {
    ID         string
    HospitalID string
    Type       string
    Status     EquipmentStatus
}

Possible states:

  • available
  • reserved
  • in_use
  • maintenance
  • failed

Equipment Reservation

Procedures requiring equipment must reserve it for a time interval.

The system must prevent overlapping reservations for the same equipment.

Medical Procedure

type MedicalProcedure struct {
    ID          string
    PatientID   string
    DoctorID    string
    Type        string
    StartTime   time.Time
    EndTime     time.Time
    EquipmentIDs []string
    Status      ProcedureStatus
}

Operating Room

type OperatingRoom struct {
    ID         string
    HospitalID string
    Status     OperatingRoomStatus
}

Possible states:

  • available
  • reserved
  • in_use
  • cleaning
  • maintenance
  • closed

Surgery

A surgery may require:

  • operating room
  • surgeon
  • assistant surgeon
  • anesthesiologist
  • nurses
  • equipment
  • patient

A possible model:

type Surgery struct {
    ID              string
    PatientID       string
    OperatingRoomID string
    SurgeonIDs      []string
    StaffIDs        []string
    EquipmentIDs    []string
    StartTime       time.Time
    EndTime         time.Time
    Priority        SurgeryPriority
    Status          SurgeryStatus
}

Surgery Scheduling

A surgery may be scheduled only when all required resources are simultaneously available.

The scheduler must validate:

  • operating room availability
  • doctor availability
  • staff shifts
  • staff schedule conflicts
  • equipment availability
  • patient availability

A resource conflict invalidates the proposed schedule.

Surgery Priority

Possible priorities:

  • elective
  • urgent
  • emergency

Emergency surgery has the highest priority. Urgent surgery has priority over elective surgery. Priority alone does not permit silently deleting existing schedules. Any displacement must be represented as an explicit rescheduling operation.

Surgery Conflict Scenario

Suppose:

        S01:
            OR-01
            14:00 -> 16:00
            elective
        
        S02:
            OR-01
            15:00 -> 17:00
            urgent

Both cannot use the room simultaneously.

The scheduler must reject the conflicting schedule or explicitly reschedule one surgery.

Patient Transfer

A patient may need a resource unavailable at the current hospital. Example:

H01 has no available ICU bed
H02 has ICU capacity

Create:

type PatientTransfer struct {
    ID             string
    PatientID      string
    SourceHospitalID string
    TargetHospitalID string
    Reason         string
    Status         TransferStatus
}

Possible states:

requested
approved
in_transit
completed
cancelled

Transfer Validation

Before transfer:

  • target hospital must exist
  • target hospital must support required department
  • required bed must be available
  • required resources must exist
  • patient must be transportable

For the base task, transportability may be represented as an explicit boolean decision rather than inferred medically.

Discharge

A patient may be discharged when the responsible medical process explicitly permits it. The system should:

- close admission
- record discharge time
- release bed
- preserve medical history
- create cleaning requirement

After discharge:

Bed.Status = cleaning

The bed becomes:

available

only after cleaning is completed.

Patient Medical History

The system should be able to produce a patient history containing:

  • appointments
  • admissions
  • diagnoses
  • treatments
  • medication orders
  • medication administrations
  • laboratory tests
  • procedures
  • surgeries
  • transfers
  • discharges

Historical records must not disappear when current state changes.

Hospital Capacity

Create a hospital-capacity report. Example:

Hospital: H01

General Beds:
Total      = 120
Occupied   = 94
Available  = 18
Unavailable = 8

ICU Beds:
Total      = 20
Occupied   = 18
Available  = 2

Operating Rooms:
Total      = 8
Available  = 3
In Use     = 4
Maintenance = 1

The system should support:

find hospitals capable of accepting this patient

Criteria may include:

  • department
  • bed type
  • required equipment
  • specialist availability

Results should be deterministic.

A reasonable ordering is:

  • highest resource suitability
  • then lowest HospitalID

Distance is not part of the base task unless explicitly added.

Resource Failure

Medical resources may fail. Example:

CT-01 fails at 11:20

The system must identify:

  • currently affected procedure
  • future reservations
  • patients waiting for the equipment

Possible recovery actions:

  • use another machine
  • reschedule procedure
  • transfer patient

The selected action must be explicit.

Staff Unavailability

A doctor may unexpectedly become unavailable. The system must identify affected:

  • appointments
  • procedures
  • surgeries

Possible recovery:

  • replacement staff
  • rescheduling
  • cancellation
  • patient transfer

Operational Event

Create a general operational event model.

type OperationalEvent struct {
    ID         string
    Timestamp  time.Time
    HospitalID string
    EntityType string
    EntityID   string
    EventType  string
    Details    string
}

Examples:

  • patient admitted
  • bed allocated
  • emergency priority changed
  • surgery scheduled
  • surgery postponed
  • equipment failed
  • patient transferred
  • patient discharged

Idempotency

Important commands should contain RequestID. Examples:

  • create appointment
  • admit patient
  • schedule surgery
  • create transfer
  • discharge patient
  • dispense medication

Processing the same request twice must not:

  • create duplicate appointments
  • allocate two beds
  • schedule duplicate surgeries
  • transfer the same patient twice
  • dispense medication twice
  • discharge twice

Domain Invariants

The implementation must preserve important invariants.

Examples:

        one bed cannot be occupied by two active admissions
        
        one operating room cannot contain overlapping surgeries
        
        one doctor cannot participate in overlapping procedures
        
        unavailable equipment cannot be reserved
        
        medication stock cannot become negative
        
        discharged patient cannot remain assigned to an occupied bed
        
        completed transfer cannot leave two active admissions
        
        patient history must not be deleted when current state changes

Query Operations

Support queries such as:

  • get patient
  • get patient medical history
  • get doctor schedule
  • get available doctors
  • get available beds
  • get hospital capacity
  • get emergency queue
  • get active admissions
  • get scheduled surgeries
  • get available operating rooms
  • get equipment status
  • get pending laboratory tests
  • find suitable hospital
  • get patient medications

Queries must not modify state.

Command Operations

State-changing operations include:

  • create appointment
  • cancel appointment
  • register emergency case
  • update triage priority
  • admit patient
  • allocate bed
  • create diagnosis
  • create treatment plan
  • order medication
  • administer medication
  • request laboratory test
  • complete laboratory test
  • schedule procedure
  • schedule surgery
  • reschedule surgery
  • transfer patient
  • mark equipment failed
  • restore equipment
  • discharge patient
  • complete bed cleaning

Validation

Validate:

  • duplicate IDs
  • unknown hospital
  • unknown department
  • unknown patient
  • unknown doctor
  • unknown nurse
  • unknown room
  • unknown bed
  • unknown equipment
  • unknown medication
  • invalid time interval
  • appointment conflict
  • staff schedule conflict
  • operating-room conflict
  • equipment conflict
  • bed already occupied
  • invalid ward type
  • insufficient medication stock
  • invalid state transition
  • duplicate RequestID

Required Test Scenarios

Create tests for at least:

  • successful appointment
  • appointment conflict
  • doctor unavailable
  • emergency queue ordering
  • same-priority emergency ordering
  • successful admission
  • no available bed
  • ICU allocation
  • duplicate bed allocation prevention
  • successful diagnosis creation
  • medication order
  • successful medication administration
  • insufficient medication stock
  • laboratory test lifecycle
  • equipment reservation
  • equipment conflict
  • successful surgery scheduling
  • operating-room conflict
  • staff conflict
  • emergency surgery preemption
  • scheduled surgery rescheduling
  • equipment failure
  • doctor becomes unavailable
  • successful patient transfer
  • transfer rejected because target has no bed
  • successful discharge
  • bed enters cleaning state
  • bed becomes available after cleaning
  • patient history generation
  • hospital capacity report
  • duplicate admission request
  • duplicate medication administration request

Large Network Scenario

Create a test dataset containing at least:

  • 3 hospitals
  • 12 departments
  • 20 wards
  • 60 rooms
  • 120 beds
  • 40 doctors
  • 60 nurses
  • 100 patients
  • 50 appointments
  • 20 active admissions
  • 10 operating rooms
  • 25 medical devices
  • 15 scheduled procedures
  • 8 scheduled surgeries
  • 20 medication orders
  • 15 laboratory tests

Then simulate:

  • one P1 emergency arrival
  • one ICU capacity exhaustion
  • one operating-room conflict
  • one equipment failure
  • one doctor becoming unavailable
  • one inter-hospital patient transfer

Verify that all affected resources and patient states remain consistent.

Modeling Goal

The purpose of this task is to model a system where human priority, scheduling, physical resources, and long-lived history interact.

A useful conceptual architecture is:

        Hospital Registry
              |
              +-- Hospitals
              +-- Departments
              +-- Wards
              +-- Rooms
              +-- Beds
              |
              v
        Patient Service
              |
              +-- Patients
              +-- Appointments
              +-- Admissions
              +-- Medical History
              |
              v
        Emergency Service
              |
              +-- Triage
              +-- Priority Queue
              +-- Emergency Allocation
              |
              v
        Clinical Service
              |
              +-- Diagnoses
              +-- Treatments
              +-- Medications
              +-- Laboratory
              |
              v
        Scheduling Service
              |
              +-- Doctors
              +-- Staff
              +-- Equipment
              +-- Operating Rooms
              +-- Surgeries
              |
              v
        Capacity and Transfer Service
              |
              +-- Bed Allocation
              +-- Hospital Capacity
              +-- Patient Transfer
              |
              v
        Operational History

The main challenge is maintaining consistency when several limited resources are required by the same medical operation and when emergency priority changes an already planned schedule.

Scalionix Docs

Keyboard Shortcuts

Navigate the documentation without leaving the keyboard.
Navigation
Previous subject
←
Next subject
→
Previous subsection
Alt + ↑
Next subsection
Alt + ↓
Interface
Documentation Home
Ctrl + Enter
Search
Alt + Q
Open shortcuts
?
Close dialog
Esc
Scalionix Docs

Search Documentation