How irani-ewu/hospital-management-system works
1. This is a small, CLI-based hospital management system written in Python with an OOP design. The application is organized into three domain modules plus a single entry script: patient.py, staffs.py, treatment.py, and main.py.
2. main.py is the orchestration layer. It likely contains the menu loop, gathers user input, creates the right domain objects, and routes each action to the correct class. There is no separate web server, database, or background service.
3. patient.py represents the patient subsystem. The README indicates patients have a name, ID, and symptoms, and that symptoms are encapsulated as a private field. The patient object also has a show_details() style method used for displaying patient data in a consistent way.
4. staffs.py is the staff-management subsystem. It centers on a shared StaffProfile base class, with Doctor and Nurse as subclasses. This is the main inheritance boundary in the project and is used to reduce duplication across staff types.
5. The staff model is role-specific: doctors carry degree and specialty information, while nurses carry shift information. Both roles likely implement their own show_details() behavior, which fits the repo’s polymorphism claim.
6. treatment.py appears to handle the consultation or interaction workflow. This is where a doctor object is matched with a patient object, symptoms are compared against specialty, and a prescription can be generated if the pairing is appropriate.
7. The data flow is file-centric. Patient and staff entries are saved as individual text files rather than stored in memory only or in a database. The repository tree shows example output files such as 1'no. patient's data, 2'no. patient's data, and D1'no. staff's data.
8. Consultation produces additional output files. The sample D1'no. Dr. prescription for '1' suggests a doctor-specific prescription file is created as a result of a successful patient-doctor interaction. This makes treatment records a separate artifact from patient registration.
9. The main architectural boundary is between user interaction, domain logic, and persistence. main.py handles command flow, the domain classes encapsulate hospital entities and rules, and plain text files serve as the persistence layer.
10. The system is intentionally simple and local. It is designed for practice and demonstration of OOP concepts, not for concurrency, authentication, multi-user access, or scalable storage. All state is managed through objects and text files in the working directory.
11. The most important runtime dependency is the Python interpreter itself. No external frameworks are indicated in the README, so the architecture is self-contained and portable as a folder of .py files plus generated .txt-style records.
12. For an architecture diagram, the key flows are: user input in the CLI -> object creation in patient.py or staffs.py -> file write to patient/staff records -> consultation in treatment.py -> prescription file generation. That is the core end-to-end lifecycle of the repository.
Main entry points: main.py main.py · treatment.py Treatment · patient.py Patients · staffs.py Staff
Components 8
Orchestration
CLI flow and application entrypoint
- main.py · Entry script that drives menus, input, object creation, and action routing
main.py
Domain
Hospital entities and treatment rules
Artifacts
Generated text records in the working directory
- Patient 1 · Generated patient data file
'1'no. patient's data - Patient 2 · Generated patient data file
'2'no. patient's data - Doctor data · Generated staff data file for a doctor profile
'D1'no. staff's data - Prescription · Generated doctor prescription output for a patient consultation
'D1'no. Dr. prescription for '1'
Connections 12
- main.py → Patients: creates · Builds patient objects from CLI input
- main.py → Staff: creates · Builds doctor and nurse objects from CLI input
- main.py → Treatment: routes · Dispatches consultation and workflow actions
- Patients → Patient 1: writes · Persists patient details as a text record
- Patients → Patient 2: writes · Persists patient details as a text record
- Staff → Doctor data: writes · Persists staff details as a text record
- Treatment → Patients: reads · Uses patient symptoms during consultation
- Treatment → Staff: reads · Uses doctor specialty and staff role data
- Treatment → Prescription: generates · Creates prescription output when pairing is appropriate
- main.py → Patient 1: manages · Coordinates the end-to-end file-based lifecycle
- main.py → Doctor data: manages · Coordinates the end-to-end file-based lifecycle
- main.py → Prescription: manages · Coordinates the end-to-end file-based lifecycle