🏥 Medical Appointment System – Backend Activity

📌 Objetivo

Implementar los endpoints necesarios para que el sistema de gestión de citas médicas funcione completamente, respetando:

• El ERD proporcionado
• El patrón de arquitectura entregado
• Buenas prácticas REST
• Separación por capas (Controller → Service → Repository)

---

🗂 Modelo de Datos (ERD)

El sistema está compuesto por las siguientes entidades:

• PATIENT
• DOCTOR
• SPECIALTY
• APPOINTMENT
• PAYMENT
• PRESCRIPTION

Relaciones principales:

• Un PATIENT puede tener muchas APPOINTMENT
• Un DOCTOR puede tener muchas APPOINTMENT
• Un SPECIALTY puede tener muchos DOCTOR
• Una APPOINTMENT tiene:
  • 1 PAYMENT
  • Muchas PRESCRIPTION

---

🧱 Arquitectura Obligatoria

Deben seguir el patrón ya entregado:

/controllers
/services
/repositories
/routes

Responsabilidades

Controller

• Recibir request
• Validar entrada básica
• Llamar al service
• Retornar respuesta HTTP

Service

• Contener lógica de negocio
• Orquestar repositorios
• No interactuar directamente con req/res

Repository

• Acceso a base de datos
• Queries SQL
• Nada de lógica de negocio

---

🚀 Endpoints a Implementar

🧑‍⚕️ 1. Specialties

Crear especialidad

POST /specialties

Listar especialidades

GET /specialties

---

👨‍⚕️ 2. Doctors

Crear doctor

POST /doctors

Debe validar:

• Que specialty_id exista.

Listar doctores

GET /doctors

Filtrar por especialidad

GET /doctors?specialty_id=uuid

---

👤 3. Patients

Crear paciente

POST /patients

Listar pacientes

GET /patients

Obtener paciente por ID

GET /patients/:id

---

📅 4. Appointments

Crear cita

POST /appointments

Debe validar:

• Que el paciente exista.
• Que el doctor exista.
• Que el doctor pertenezca a la especialidad correcta.
• Que la fecha sea válida.

Listar citas

GET /appointments

Obtener citas por paciente

GET /patients/:id/appointments

Obtener citas por doctor

GET /doctors/:id/appointments

---

💊 5. Prescriptions

Crear prescripción para una cita

POST /appointments/:id/prescriptions

Debe validar:

• Que la cita exista.

Listar prescripciones por cita

GET /appointments/:id/prescriptions

---

💳 6. Payments

Registrar pago

POST /appointments/:id/payment

Debe validar:

• Que la cita exista.
• Que no exista ya un pago (relación 1:1).

Obtener pago de una cita

GET /appointments/:id/payment

---

📌 Reglas de Negocio Obligatorias

1. No se puede crear un doctor sin especialidad válida.
2. No se puede crear una cita con paciente o doctor inexistente.
3. No se puede registrar más de un pago por cita.
4. Las fechas deben ser coherentes (no permitir fechas inválidas).
5. Las relaciones deben respetar el ERD.

---

🧪 Validaciones Esperadas

• Manejo correcto de errores (400, 404, 500).
• Respuestas en formato JSON consistente.
• No exponer errores internos de base de datos.
• Manejo de UUID correctamente.

---

🏗 Patrón Esperado en el Código

Ejemplo estructural:

appointments.controller.ts
appointments.service.ts
appointments.repository.ts
appointments.routes.ts

El controller no debe :

• Contener queries SQL.
• Contener lógica compleja.

El repository no debe :

• Validar reglas de negocio.
• Tomar decisiones.

---

🎯 Objetivo Final

Al finalizar la actividad, el sistema debe permitir:

• Registrar pacientes
• Registrar doctores
• Asignar especialidades
• Crear citas
• Registrar prescripciones
• Registrar pagos
• Consultar relaciones completas

El sistema debe funcionar completamente según el ERD.

---

🏆 Criterios de Evaluación

Se evaluará:

• Correcta implementación de endpoints
• Respeto del patrón de arquitectura
• Calidad del código
• Validaciones correctas
• Manejo adecuado de errores
• Claridad en la organización del proyecto

---

🚨 Restricciones

• No modificar el modelo de datos.
• No mezclar responsabilidades entre capas.
• No usar lógica en rutas.
• No usar consultas directas desde el controller.

---

📦 Entregables

• Proyecto funcional
• Código organizado por módulos
• Base de datos funcionando
• README actualizado si agregan algo adicional