How cesaradso/e-vitalix works
1. What this repository is
- E-VITALIX is a PHP MVC-style health management platform.
- The system centers on patients, appointments, clinical histories, medical consultations, tickets, and user profiles.
- It is organized as a multi-role application rather than a generic CRUD app.
2. Application boundary and entry point
- index.php acts as the main application entry/front controller.
- The codebase is split into classic MVC layers under app/controllers, app/models, and app/views.
- vendor/ and composer.json indicate Composer-managed dependencies for runtime services such as PDF/mail or framework support.
3. Role-based architecture
- The platform is explicitly segmented by user type:
- superadministrador
- administrador consultorio
- asistente
- especialista
- paciente
- Each role has its own dashboard controller, views, layout, and session guard helper.
- This is the main architectural boundary: each role gets a separate UI and permitted workflow set.
4. Authentication, authorization, and sessions
- LoginController, registroController, passwordController, and cerrarSesionController handle auth lifecycle.
- Session enforcement is split into role-specific helpers:
- session_superadmin.php
- session_administrador.php
- session_asistente.php
- session_especialista.php
- session_paciente.php
- This makes access control a cross-cutting concern that sits between controllers and views.
5. Core domain: scheduling and care workflow
- The clinical workflow is built around:
- citaController, calendarioController, horarioController, slotController
- consultaMedicaController
- historialesController
- The patient path likely flows from searching consultorios/especialistas, choosing availability, booking/reprogramming citas, and then recording consultation + history.
6. Organization and master-data management
- Administrative entities are modeled separately and maintained through dedicated controllers/models:
- consultorio, especialista, paciente, usuario, roles
- especialidad, ciudades, tipoDocumento, aseguradora, planes
- The superadmin area also manages consultorios, administrators, and global user records.
- These modules act as reference/master data used by scheduling and onboarding flows.
7. Ticketing and support workflow
- ticketController and related views implement a support/ticket system.
- Multiple roles can create, consult, update, and respond to tickets.
- This is an operational subsystem separate from the medical workflow, but tied to user accounts and dashboards.
8. Reporting and document generation
- PDF output is a dedicated subsystem:
- reportesPdfController
- role-specific variants for administrador, especialista, and paciente
- PDF views under app/views/pdf
- pdf_helper.php
- The architecture treats report generation as a separate read-only projection of domain data, not as part of the transactional UI.
9. Helpers and cross-cutting services
- validacion_helper.php centralizes server-side validation rules.
- mailer_helper.php suggests email-based flows such as registration/recovery/notifications.
- notificacionCIta.php indicates appointment notification logic.
- alert_helper.php supports UI feedback/flash-style messaging.
- These helpers are used across controllers rather than owning business state.
10. Presentation layer structure
- Views are grouped by concern:
- app/views/auth for login, registration, recovery, 404
- app/views/dashboard/<rol> for role-specific operations
- app/views/layouts for reusable headers/sidebars/topbars/footers
- app/views/website for the public landing page
- This layout shows a strong separation between public marketing/auth pages and authenticated dashboards.
11. Static assets and client-side validation
- public/assets contains CSS, JavaScript, and role-specific UI assets.
- public/assets/js/validaciones.js and public/assets/css/validaciones.css support frontend validation.
- The dashboard and auth screens have separate asset bundles, reinforcing the split between public and internal experiences.
12. File uploads and persisted artifacts
- public/uploads holds uploaded or generated files, organized by entity:
- consultorios, pacientes, tickets, usuarios
- The presence of SQL files under uploads suggests this repo also stores database scripts/migrations/backups as operational artifacts.
- This directory is part of the application’s persistence boundary, outside the MVC request flow.
13. Reference data / seed-like JSON
- public/assets/data/*.json contains consultorio, especialidad, and usuario data.
- These files likely serve as sample datasets, imports, or frontend reference content.
- They are separate from the main transactional model layer.
14. How the main data flow works
- Typical flow: user enters through auth → session helper authorizes role → role dashboard controller loads data from model → view renders with shared layout → optional PDF/mail/notification side effects.
- The important architectural separation is between:
- request handling in controllers,
- business/persistence in models,
- presentation in views,
- cross-cutting services in helpers,
- and role enforcement in session helpers.
Main entry points: especialistaDashboardController.php Especialista · pacienteDashboardController.php Paciente · dashboard-administrador.php Dashboards · index.php Front controller
Components 21
Application
Front controller, MVC layers, and cross-cutting helpers.
- Front controller · Main application entry that routes requests into the MVC app.
index.php - Session guards · Role-specific session enforcement for superadmin, administrador, asistente, especialista, and paciente.
app/helpers/session_superadmin.php - Composer deps · Third-party runtime libraries managed by Composer.
vendor
Role areas
Separate dashboards and workflows by user type.
- Superadmin · Superadministrador control plane for users, consultorios, and tickets.
app/controllers/superAdminDashboardController.php - Admin · Administrador consultorio workspace for specialists, assistants, plans, and tickets.
app/controllers/adminConsultorioDashboardController.php - Asistente · Assistant workspace for patients and ticket handling.
app/controllers/asistenteController.php - Especialista · Specialist workspace for availability, consultations, patients, and tickets.
app/controllers/especialistaDashboardController.php - Paciente · Patient workspace for appointments, profile, history, and tickets.
app/controllers/pacienteDashboardController.php
Domain services
Core scheduling, clinical, identity, and support subsystems.
- Auth flow · Login, registration, password recovery, and logout controllers.
app/controllers/LoginController.php - Agenda · Citas, calendarios, horarios, and available slots.
app/controllers/citaController.php - Clinical care · Consultation and clinical history workflows.
app/controllers/consultaMedicaController.php - Master data · Consultorio, especialista, paciente, usuario, roles, especialidad, ciudades, aseguradora, planes, and tipo documento management.
app/controllers/consultorioController.php - Tickets · Cross-role support ticket creation, tracking, and responses.
app/controllers/ticketController.php - PDF reports · Read-only PDF generation for multiple roles and clinical records.
app/controllers/reportesPdfController.php
Presentation
Auth, dashboards, layouts, PDF views, and public website.
- Auth views · Login, registration, recovery, and 404 screens.
app/views/auth/inicioSesion.php - Dashboards · Role-specific dashboard pages and operations.
app/views/dashboard/administrador/dashboard-administrador.php - Layouts · Shared headers, sidebars, topbars, and footers per role.
app/views/layouts/header_superadministrador.php - PDF views · Templates used to render administrative and clinical PDFs.
app/views/pdf/consulta_medica_pdf.php - Public site · Landing page and public-facing website presentation.
app/views/website/index.php
Assets and data
Client assets, static data, and uploaded artifacts.
- Static assets · CSS, JavaScript, images, validation scripts, and sample JSON data.
public/assets/dashboard/js/dashboards.js - Uploads · Uploaded files and generated artifacts, including entity-organized storage and SQL backups.
public/uploads
Connections 46
- Front controller → Auth flow: routes auth · Front controller dispatches unauthenticated and identity flows.
- Front controller → Superadmin: routes role UI · Routes authenticated users into the correct role area.
- Front controller → Admin: routes role UI · Routes authenticated users into the correct role area.
- Front controller → Asistente: routes role UI · Routes authenticated users into the correct role area.
- Front controller → Especialista: routes role UI · Routes authenticated users into the correct role area.
- Front controller → Paciente: routes role UI · Routes authenticated users into the correct role area.
- Auth flow → Session guards: sets guards · Authentication lifecycle depends on role-based session checks.
- Session guards → Superadmin: authorizes · Superadmin sessions gate access to the superadmin dashboard.
- Session guards → Admin: authorizes · Administrador sessions gate access to the admin dashboard.
- Session guards → Asistente: authorizes · Asistente sessions gate access to the assistant dashboard.
- Session guards → Especialista: authorizes · Especialista sessions gate access to the specialist dashboard.
- Session guards → Paciente: authorizes · Paciente sessions gate access to the patient dashboard.
- Superadmin → Master data: manages · Superadmin area administers global entities and consultorios.
- Admin → Master data: manages · Administrator area maintains specialists, assistants, plans, and related records.
- Asistente → Master data: uses · Assistant workflows depend on patient and user records.
- Especialista → Agenda: uses · Specialist schedules and availability are centered on the agenda subsystem.
- Paciente → Agenda: uses · Patient booking and reprogramming depend on scheduling.
- Agenda → Master data: reads · Scheduling depends on consultorio, especialista, and patient reference data.
- Agenda → Clinical care: feeds · Booked encounters become consultation and history inputs.
- Especialista → Clinical care: records · Specialist records consultations and reviews histories.
- Paciente → Clinical care: views · Patient dashboard exposes clinical history and consultation records.
- Superadmin → Tickets: handles · Superadmin can respond to and manage tickets.
- Admin → Tickets: handles · Administrator can create, consult, and update support tickets.
- Asistente → Tickets: handles · Assistant can create and track support tickets.
- Especialista → Tickets: handles · Specialist can create and update support tickets.
- Paciente → Tickets: handles · Patient can create and follow support tickets.
- Superadmin → PDF reports: exports · Superadmin reporting area generates PDFs from domain data.
- Admin → PDF reports: exports · Administrator reporting area generates PDFs from domain data.
- Especialista → PDF reports: exports · Specialist reporting area generates PDFs from domain data.
- Paciente → PDF reports: exports · Patient reporting area generates PDFs from domain data.
- PDF reports → PDF views: renders · PDF controller uses dedicated PDF templates.
- Auth flow → Auth views: renders · Authentication controller serves auth pages.
- Superadmin → Dashboards: renders · Role controller composes dashboard screens.
- Admin → Dashboards: renders · Role controller composes dashboard screens.
- Asistente → Dashboards: renders · Role controller composes dashboard screens.
- Especialista → Dashboards: renders · Role controller composes dashboard screens.
- Paciente → Dashboards: renders · Role controller composes dashboard screens.
- Dashboards → Layouts: includes · Dashboards are assembled from shared role-specific layouts.
- Public site → Static assets: uses · Public site pulls from website assets and scripts.
- Auth views → Static assets: uses · Auth screens use dedicated auth assets and validation scripts.
- Dashboards → Static assets: uses · Dashboard screens use dashboard CSS, JS, and assets.
- PDF views → Static assets: uses · PDF templates rely on app data but remain separated from transactional UI assets.
- Auth flow → Composer deps: depends on · Authentication and related services use Composer-managed libraries.
- PDF reports → Composer deps: depends on · PDF generation likely relies on external Composer packages.
- Clinical care → Uploads: persists · Clinical artifacts and generated files are stored under uploads.
- Tickets → Uploads: persists · Ticket attachments and artifacts are stored under uploads.