The system uses three main roles: ROLE_PATIENT, ROLE_DOCTOR, and ROLE_ADMIN. These roles are embedded securely within the Authorization JWT token during the login phase.
What this service does: Manages system registration, credential verification, and issues the JSON Web Tokens (JWT) used to access all other microservices. Base Route: /auth
- POST /auth/register
- Description: Creates a new user account in the database (Patient, Doctor, or Admin). Defaults to Patient if no role is explicitly passed.
- Who can access: 🌐 Public (No authentication required to register).
- POST /auth/login
- Description: Authenticates the user based on email and password. Generates a JWT token embedding the user's ID, Email, and Role.
- Who can access: 🌐 Public (No authentication required to log in).
What this service does: Manages all operations related to patient medical profiles, information updates, and the attachment of clinical reports. Base Route: /api/patients
- GET /api/patients/profile/{email}
- Description: Retrieves a patient's full dashboard profile utilizing their email address.
- Who can access: 🧑⚕️ PATIENT (Their own profile), DOCTOR, and ADMIN.
- GET /api/patients/{id}
- Description: Fetches a patient's details using their unique database ID.
- Who can access: 🧑⚕️ PATIENT (Their own ID), DOCTOR, and ADMIN.
- PUT /api/patients/update/{email}
- Description: Updates an existing patient’s demographic/medical information.
- Who can access: 🧑⚕️ PATIENT (Updating themselves) and ADMIN.
- POST /api/patients/{email}/report
- Description: Uploads and attaches a medical document/report to a specific patient.
- Who can access: 🧑⚕️ PATIENT and DOCTOR.
- GET /api/patients/all
- Description: Retrieves a master list of all registered patients in the clinic's database.
- Who can access: 👨⚕️ DOCTOR and 🛡️ ADMIN (Patients should never access the full list).
What this service does: Creates and tracks secure video consultation rooms and session links between doctors and patients. Base Route: /api/sessions
- POST /api/sessions/create
- Description: Initializes a new secure video consultation room right after an appointment is verified.
- Who can access: 🧑⚕️ PATIENT (During booking flow) and 🛡️ ADMIN.
- GET /api/sessions/{appointmentId}
- Description: Retrieves the exact video room link and current room status for a specific appointment.
- Who can access: 🧑⚕️ PATIENT and 👨⚕️ DOCTOR (Assigned to the appointment).
- PUT /api/sessions/{appointmentId}/start
- Description: Opens the video consultation room and flips the status to "In Progress".
- Who can access: 👨⚕️ DOCTOR (Only the doctor can officially "start" a telehealth session).
- DELETE /api/sessions/{appointmentId}/end
- Description: Concludes the telehealth call, closes the room, and flips the session status to "Completed".
- Who can access: 👨⚕️ DOCTOR (Only the doctor can designate a session as finished).
- GET /api/sessions/doctor/{doctorId}
- Description: Pulls a list of all upcoming and past video sessions assigned to a specific Doctor.
- Who can access: 👨⚕️ DOCTOR (Themselves) and 🛡️ ADMIN.
- GET /api/sessions/patient/{patientId}
- Description: Pulls a list of all video sessions assigned to a specific Patient.
- Who can access: 🧑⚕️ PATIENT (Themselves) and 🛡️ ADMIN.
- GET /api/sessions/active
- Description: Returns a system-wide view of all telemedicine sessions taking place currently.
- Who can access: 🛡️ ADMIN (Used for clinic monitoring).
otification-service) What this service does: Operates silently in the background, listening to message queues via RabbitMQ. When events happen (like a successful booking), this service automatically blasts out Emails and SMS communications to the user. Base Route: No REST Endpoints Exposed
- @RabbitListener (QUEUE_APPOINTMENT_BOOKED)
- Description: Triggers when the Appointment Service successfully creates a booking. Sends a confirmation receipt to the patient.
- Who can access: ⚙️ INTERNAL SYSTEM ONLY. No users, not even Admins, can access this service via HTTP requests. It operates securely in the background purely communicating microservice-to-microservice via the message broker.