Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Imjuanisss/proyecto-melika/llms.txt

Use this file to discover all available pages before exploring further.

Patients are the primary end users of MELIKA. After registering and verifying their email address, they can browse medical specialties, book appointments with available doctors, track upcoming and past visits on a personal calendar, and review their full clinical history — all without requiring any administrative intervention.

​
Registration

To create a MELIKA patient account, the following fields are required at sign-up:
FieldTypeValidation rules
nombrestringLetters and spaces only; min 2 chars; no digits or repeated characters
primer_apellidostringLetters and spaces only; min 2 chars; no digits or repeated characters
emailstringMust match user@domain.tld format; must be unique
passwordstringMin 6 characters; avoid trivially repeated characters (e.g. 111111)
tipo_documentoenumOne of CC, CE, or PASAPORTE
numero_documentostringDigits only, 5–15 characters; no letters or symbols; must be unique
fecha_nacimientodateFormat YYYY-MM-DD; cannot be in the future; calculated age must be 0–120 years
generoenumOne of M, F, or O
Validation is run server-side by validarRegistroUsuario. All errors are collected and returned together in a single 422 response — the request is never rejected on just the first failing field. After submission, the account is created in an unverified state and the patient is taken through the email verification step before gaining access to authenticated routes.

​
Email Verification

Before a newly registered patient can book appointments or view records, MELIKA requires email verification.
1

Code delivered

Immediately after registration, MELIKA sends a 6-digit numeric code to the provided email address. The code is valid for 15 minutes.
2

Enter the code

The patient enters the code on the verification screen. A correct submission sets both activo = TRUE and verificado = TRUE on the account, allowing the patient to log in.
3

Resend if needed

If the code expires or is not received, the patient can request a new code from the same verification screen. A fresh 15-minute window starts on every resend.
Verification codes are single-use. Requesting a resend immediately invalidates the previous code.

​
Session Storage

After a successful login, the frontend stores two entries in localStorage:
KeyContents
melika_tokenThe raw JWT string (valid for 8 hours)
melika_usuarioJSON-serialised user object (id, nombre, primer_apellido, email, rol)
These keys are read by AuthContext on page load to restore the session without requiring a new login. Both keys are removed from localStorage when the patient calls logout().

​
Booking an Appointment

Once verified, a patient can book an appointment through the following workflow:
1

Browse specialties

The specialties listing (/especialidades) is publicly accessible — no authentication is required. Patients can explore available fields of medicine before deciding to register.
2

Select a doctor

After choosing a specialty, the patient picks a doctor from the list of practitioners associated with that specialty.
3

Choose a date

The patient selects a preferred date from the doctor’s availability calendar.
4

Pick a time slot

Available 40-minute slots for the chosen date are listed. The patient selects one open slot (disponible = true).
5

Confirm the booking

The patient confirms the appointment. MELIKA sends a POST request to /citas with the following payload:
{
  "id_medico": 3,
  "id_especialidad": 1,
  "id_franja": 42,
  "fecha": "2025-08-15",
  "hora_inicio": "09:00"
}
On success, the new appointment appears immediately in the patient’s appointment list and calendar.

​
Viewing Appointments

Patients have two complementary views for tracking their appointments:
Endpoint: GET /citas/mis-citasReturns a chronological list of all appointments belonging to the authenticated patient, including their current status (pendiente, completada, cancelada, no_asistio).
GET /citas/mis-citas
Authorization: Bearer <token>

​
Cancelling an Appointment

A patient may cancel a pending appointment and, once cancelled, remove it from their list entirely.
1

Request cancellation

Send a PATCH request to /citas/:id with a mandatory cancellation reason:
{
  "razon_cancelacion": "Scheduling conflict — unable to attend"
}
The appointment status changes to cancelada. The razon_cancelacion field is required; the request is rejected without it.
2

Delete the record (optional)

After cancellation, the patient may permanently delete the appointment entry:
DELETE /citas/:id
Authorization: Bearer <token>
Only appointments with cancelada status can be deleted by a patient.

​
Clinical Records

Patients have read-only access to their own clinical history. No patient-facing route permits creating or modifying medical records.
Endpoint: GET /historias/paciente/:id_pacienteReturns all structured clinical history entries linked to the patient, including diagnoses, prescriptions, and evolution notes added by doctors.
GET /historias/paciente/7
Authorization: Bearer <token>

​
Document Visibility Control

Patients can choose to hide externally uploaded documents from their default document view. Hidden documents are not deleted — they remain accessible to authorised medical staff. 
PATCH /historias/documentos/:id/ocultar
Authorization: Bearer <token>
This route is protected by the isPaciente middleware guard, ensuring only the document’s owner can toggle its visibility.
External documents are files uploaded outside of a standard MELIKA consultation — for example, lab results from a third-party clinic, imaging files, or referral letters. They are linked to the patient’s record but carry an externo flag that distinguishes them from notes created by MELIKA doctors.

​
Dashboard and Route Guard

The patient dashboard is available at /dashboard. Access is controlled by the RutaPaciente guard defined in App.jsx, which reads the rol claim from the decoded user object stored under the melika_usuario key in localStorage.
If a user with a medico or admin role attempts to navigate to /dashboard, the RutaPaciente guard redirects them automatically to their own dashboard (/dashboard-medico or /admin, respectively). Role-based redirects work symmetrically — each guard enforces separation between the three panels.

Build docs developers (and LLMs) love

Get started for freeTalk to us