Clinic Appointment System - Project Documentation
1. Project Overview
Clinic Appointment System is a console-based application written in the C programming
language. It is designed to manage patient appointments, user accounts, and system
activities within a medical clinic environment. The system supports three distinct user
roles: Admin, Doctor, and Patient.
Data persistence is handled through binary files, ensuring that user information,
appointment schedules, and activity logs are saved between sessions. The application is
cross-platform compatible (Windows, Linux, macOS).
2. Key Features
• Role-Based Access Control: Secure login for Admins, Doctors, and Patients.
• User Management: Admins can create, view, and delete user accounts.
• Appointment Scheduling: Patients can book appointments with specific doctors
based on availability.
• Appointment Management: Doctors can view schedules, add notes, and mark
appointments as completed or cancelled.
• History Tracking: Patients and Doctors can view past appointment history.
• System Logging: All critical actions (logins, creations, cancellations) are recorded in a
log file for audit trails.
• Password Management: Users can change their own passwords.
• Dashboard Statistics: Admins can view system-wide statistics (total users, upcoming
appointments).
3. System Requirements
• Compiler: GCC (GNU Compiler Collection), Clang, or MSVC.
• Operating System: Windows, Linux, or macOS.
• Libraries: Standard C Library (stdio.h, stdlib.h, string.h, time.h).
• Disk Space: Minimal (stores data in .dat files).
4. Installation & Compilation
4.1. Compilation
To compile the source code (assuming the file is named clinic_system.c):
On Linux/macOS:
bash
Copy code
gcc clinic_system.c -o clinic_system
On Windows (using MinGW/GCC):
bash
Copy code
gcc clinic_system.c -o clinic_system.exe
4.2. Running the Application
Execute the compiled binary:
bash
Copy code
./clinic_system
(On Windows: clinic_system.exe)
4.3. Default Credentials
Upon the first run, the system initializes and creates a default Admin account.
• Phone: admin
• Password: admin123
5. User Guide
5.1. Main Menu
Upon starting, the user is presented with a login menu:
1. Admin: Full system control.
2. Doctor: Manage appointments and patient history.
3. Patient: Book and manage personal appointments.
4. Exit: Terminate the program.
5.2. Admin Dashboard
• View System Statistics: Displays counts of Doctors, Patients, and Appointments.
• Manage Users:
• Create: Add new Doctors or Patients (requires unique phone number).
• View: List all registered users.
• Delete: Remove a user (Default admin cannot be deleted).
• View All Appointments: See the entire schedule of the clinic.
• View System Logs: Audit trail of all system activities.
5.3. Doctor Dashboard
• View Upcoming Appointments: Filter by "Scheduled" status.
• Manage Appointment: Select an appointment ID to:
• Add/Update medical notes.
• Mark as "Completed".
• View Patient History: Search by patient phone number to see past visits.
• Change Password: Update login credentials.
5.4. Patient Dashboard
• Book Appointment: Select a doctor, date, and time. The system checks for conflicts.
• View Upcoming Appointments: See scheduled visits.
• View Past Appointments: See completed or cancelled visits.
• Cancel Appointment: Cancel a scheduled appointment by ID.
• Change Password: Update login credentials.
6. Technical Architecture
6.1. Data Structures
The system uses three primary struct definitions stored in memory and written to binary
files:
1. User: Stores account details.
• Fields: phone, name, password, role, registration_date.
2. Appointment: Stores visit details.
• Fields: id, patient_phone, patient_name, doctor_phone, doctor_name, date,
time, notes, status.
3. Log: Stores audit trail entries.
• Fields: timestamp, activity_type, details.
6.2. File Persistence
The system relies on three binary files located in the working directory:
• [Link]: Contains the User struct array.
• [Link]: Contains the Appointment struct array.
• [Link]: Contains the Log struct array.
File Operations:
• Reading: fopen(..., "rb")
• Writing/Appending: fopen(..., "ab")
• Updating: fopen(..., "rb+") (Read/Write mode used for modifying existing records).
• Deletion: Implemented by reading the original file, writing non-deleted records to
a [Link] file, then replacing the original file.
6.3. Global State
Session state is maintained using global variables:
• loggedInUserPhone
• loggedInUserName
• loggedInUserRole
These variables are populated upon successful authentication and used to filter data (e.g.,
showing only the logged-in doctor's appointments).
7. Security & Limitations
7.1. Security Warning
Plain Text Passwords: For simplicity in this educational project, passwords are stored
in plain text within [Link]. In a production environment, passwords should be hashed
(e.g., using SHA-256) before storage.
No Encryption: Data files are not encrypted. Anyone with file system access can read the
contents of [Link] and [Link].
7.2. Limitations
• Concurrency: The system does not handle multi-user access simultaneously. If two
users try to book the same slot at the exact same time, race conditions may occur.
• Input Validation: While basic checks exist (e.g., phone number uniqueness), input
sanitization is minimal.
• Data Integrity: There is no database transaction rollback mechanism. If the program
crashes during a file write, data corruption could occur.
• No Network: This is a local application. It does not support remote access or web
interfaces.
8. File Structure
text
Copy code
/ProjectRoot
├── clinic_system.c (Source Code)
├── clinic_system (Compiled Binary)
├── [Link] (User Database)
├── [Link] (Appointment Database)
├── [Link] (Activity Logs)
└── [Link] (Temporary file used during user deletion)
9. Future Enhancements
To upgrade this project to a production-ready standard, consider the following:
1. Database Integration: Replace binary files with SQLite or MySQL.
2. Password Hashing: Implement bcrypt or SHA-256 for password storage.
3. GUI: Port the interface to GTK, Qt, or a Web Framework (React/[Link]).
4. Concurrency: Add mutex locks to prevent race conditions during file writes.
5. Validation: Add regex validation for phone numbers and date formats.