CABA Clinic Appointment Platform

A clinic appointment is not one isolated form submission. The system must coordinate doctor availability, morning and evening periods, capacity limits, appointment types, confirmation decisions, notes, results, cancellations, and role-specific permissions.

The same application also had to remain understandable for three very different users. Patients need a simple booking journey, doctors need schedule and consultation controls, and receptionists need broad administrative access without exposing those controls to everyone.

The challenge was to model these rules clearly while keeping the interface responsive, bilingual, and manageable as the amount of clinic content and operational data grows.

• Patient journey. Let patients discover doctors, review profiles and availability, request new or follow-up appointments, and manage active bookings.
• Doctor workflow. Let doctors maintain profiles, define morning and evening capacity, accept or decline requests, add notes, and record visit results.
• Receptionist control. Provide administration for doctors, specialties, appointments, public content, contact methods, social links, opening hours, branding, and configuration.
• Academic scope. Deliver a complete bilingual application without payments, insurance processing, medical-record integration, or claims of production-clinic readiness.

• Requirements analysis and role-permission modeling.
• Information architecture and end-to-end user-flow planning.
• Responsive bilingual UI design and front-end implementation.
• PHP controller and application-logic development with Twig integration.
• MySQL data modeling and appointment-state handling.
• Manual testing, validation, and technical documentation.

1. Model the roles first. Patient, doctor, and receptionist responsibilities were defined before the screens so each action had a clear owner and permission boundary.
2. Define appointment states and constraints. Availability, period capacity, request confirmation, cancellation, follow-up appointments, attendance, notes, and results were treated as connected business rules.
3. Separate presentation from application logic. Twig templates and shared layouts handle presentation, while PHP classes and API-style controllers manage data and operations through PDO and MySQL.
4. Test complete journeys. The work was reviewed from account access through booking, doctor response, schedule management, administration, notifications, and bilingual interface behavior.

• Patient experience. Doctor discovery, profile details, working-day availability, appointment type, notes, and booking management are joined into one predictable journey.
• Doctor workspace. Doctors control bilingual profile information, publish dated morning and evening capacity, respond to requests, and record consultation results.
• Receptionist administration. A broad control panel manages clinical entities, appointments, public-page content, opening hours, contact channels, branding, and configuration.
• Application foundation. PHP 8, Twig, PDO and MySQL, reusable templates, Sass, Bootstrap, JavaScript, jQuery, and AJAX support the complete role-based application.

The interface uses labeled forms, visible actions, responsive layouts, and clear validation and status feedback. Dedicated RTL styles and Arabic phrases support right-to-left presentation rather than relying only on translated text.

A current WCAG conformance audit was not part of the original academic scope, so the project should not be presented with a formal accessibility compliance claim.

Server-rendered PHP and Twig pages provide the main application structure, while AJAX is used for targeted form, filtering, notification, and management actions. Compiled and minified CSS and JavaScript reduce unnecessary front-end weight.

No verified production performance score is claimed because the supplied project is an academic codebase rather than a monitored live deployment.

Manual testing covered authentication, role permissions, profile updates, doctor availability, capacity rules, duplicate-booking restrictions, appointment requests, acceptance and decline flows, cancellation, consultation results, notifications, content controls, and responsive layouts.

English and Arabic phrase loading and RTL styling were also reviewed. The repository does not include an automated application test suite, so that limitation remains explicit.

• Working three-role platform. The delivered application connects patient, doctor, and receptionist workflows instead of demonstrating isolated screens.
• Structured operational model. The database snapshot defines 23 tables for users, sessions, roles, appointments, schedules, notifications, specialties, content, and configuration.
• Reusable bilingual foundation. Shared Twig layouts, language files, RTL styles, and reusable JavaScript workflows make the application broader than a one-page prototype.
• Honest scope. CABA demonstrates a complete academic product workflow while keeping production medical, security, and operational claims outside the case study.

• Model permissions and appointment states before designing the interface. This prevents contradictory actions and makes validation easier to explain.
• Bilingual applications require data and layout decisions, not only translated labels. Profiles, public content, direction, spacing, and defaults all need deliberate handling.
• Administrative content controls can make a custom application more maintainable without turning it into a generic CMS.
• Before production use, the application would require security modernization, including contemporary password hashing, stricter upload validation, hardened session cookies, secret management, and operational monitoring.