Project Progress Summary: Codeline Health Care Center

As part of our ongoing development of the Codeline Health Care Center System, significant foundational work has been successfully completed, setting a strong structural and architectural base for the system. The project is being designed following object-oriented programming principles and a modular architecture to ensure scalability, maintainability, and clarity.

1. System Planning and Class Design

We began the project by thoroughly planning the class structure of the system. This "Planning Map" outlines the core entities of the healthcare center and the relationships between them. Each class was meticulously designed with clearly defined:

Fields : Representing the attributes of each entity.

Data Types: Chosen carefully to suit the nature of each field (e.g., int, string, DateTime, List<>, etc.).

Access Modifiers: Implemented to ensure encapsulation and data protection, using public, private, and protected as appropriate.

Collections : Where applicable, List and other collections were used to model one-to-many relationships between entities.

The primary classes designed include:

• Hospital: Central entity managing branches and system-wide settings.

• Branch: Represents different physical or organizational units under the hospital.

• Department: Represents medical or administrative units (e.g., Cardiology, Billing).

• BranchDepartment: Manages the linkage between branches and their departments.

• Clinic: Represents individual clinics under departments, where patient services are offered.

• User : The base class for all system users.

• SuperAdmin / Admin / Doctor / Patient : Inherited from User, each with roles and responsibilities specific to their position.

• Booking : Handles appointment scheduling between patients and doctors/clinics.

• PatientRecord: Maintains the medical history and treatment data of patients.

• Service: Represents medical services provided by the healthcare center.

• Floor / Room : Models the physical layout of branches.

• Validation: A utility class to manage input and business rule validation.

• Additional : Placeholder for any future enhancements or utility classes.

2. Interface Design

To promote loose coupling and adhere to SOLID principles—especially the Interface Segregation and Dependency Inversion principles—we developed a comprehensive set of service interfaces. Each interface clearly defines the contract for operations related to its respective domain area. These interfaces include:

• IBookingService.cs: Handles booking logic including appointment creation, modification, and cancellation.

• IBranchService.cs: Manages branch-related operations like adding, updating, and listing branches.

• IBranchDepartmentService.cs: Facilitates management of department associations within a branch.

• IClinicService.cs: Handles clinic-related functionality including clinic creation and doctor assignments.

• IDepartmentService.cs: Deals with the CRUD operations for hospital departments.

• IDoctorService.cs : Provides methods for managing doctor information and their availability.

• IPatientService.cs : Covers operations related to patient registration and profile management.

• IPatientRecordService.cs : Defines operations for storing and retrieving patient health records.

• IUserService.cs: Provides generic user management methods applicable across roles.

• IAuthService.cs : Handles authentication and authorization logic for different types of users.

• ISuperAdminService.cs : Manages high-level administrative features exclusive to super admins, such as creating admin accounts, managing global settings, and overseeing system-wide activity.

• IAdminService.cs:Provides functionality for branch or department-level administration, such as managing local users, services, and daily operations.

Each of these interfaces has been outlined with relevant method signatures to prepare for implementation during the next phase. This design ensures that each role in the system has clearly defined responsibilities and supports the open/closed principle by allowing extension without modification.

3. Project Structure

The project structure has been organized to reflect a layered and modular design, which makes it easier to maintain and scale. The current structure includes:

• Entities/Models : Represent the system's data and business domain.

• Interfaces : Define contracts for services without binding them to concrete implementations.

• Services (To be Implemented) : Business logic implementation that adheres to the interfaces.

• Utilities : Common functionalities such as validation helpers or shared constants.

• Main Program/Startup File : For initializing and testing the system in a console or integrated environment.

This setup is intentionally designed to support future enhancements like integration with databases, APIs, or graphical user interfaces.