flowchart LR
    USER["Users<br/>Patients, Doctors, Administrators"]

    subgraph FRONTEND["Presentation Layer"]
        UI["Web Interface<br/>Pug, HTML5, Tailwind CSS, JavaScript"]
    end

    subgraph BACKEND["Backend Application - Modular Monolith"]
        ROUTES["Express Routes and Controllers"]

        SECURITY["Authentication, Authorization<br/>Request Validation and Error Handling"]

        subgraph BUSINESS["Business Modules"]
            AUTH["Authentication and Users"]
            PATIENTS["Patient Management"]
            DOCTORS["Doctors and Specialties"]
            SCHEDULES["Schedules and Availability"]
            APPOINTMENTS["Appointment Management"]
            MEDICAL["Consultations, Diagnoses<br/>and Prescriptions"]
            NOTIFICATIONS["Notification Management"]
            ADMIN["Administration, Reporting<br/>and Audit Logs"]
        end

        DATA["Data Access Layer<br/>Sequelize ORM and MySQL2"]
    end

    DB[("MySQL Database")]

    subgraph EXTERNAL["External Services"]
        WA["WhatsApp Provider"]
        EMAIL["Email Provider"]
        SMS["SMS Provider"]
    end

    USER <--> UI
    UI <-->|"HTTP/HTTPS"| ROUTES
    ROUTES --> SECURITY

    SECURITY --> AUTH
    SECURITY --> PATIENTS
    SECURITY --> DOCTORS
    SECURITY --> SCHEDULES
    SECURITY --> APPOINTMENTS
    SECURITY --> MEDICAL
    SECURITY --> NOTIFICATIONS
    SECURITY --> ADMIN

    AUTH <-->|"Credential lookup and user data"| DATA

    PATIENTS <-->|"Patient data"| DATA
    DOCTORS <-->|"Doctor and specialty data"| DATA
    SCHEDULES <-->|"Schedule data"| DATA
    APPOINTMENTS <-->|"Appointment data"| DATA
    MEDICAL <-->|"Clinical data"| DATA
    NOTIFICATIONS <-->|"Notification records"| DATA
    ADMIN <-->|"Administrative and audit data"| DATA

    DATA <-->|"SQL queries and results"| DB

    NOTIFICATIONS --> WA
    NOTIFICATIONS --> EMAIL
    NOTIFICATIONS --> SMS

The Software Component Diagram describes the logical architecture of SaludVital, a medical appointment management system. It identifies the main software components, their responsibilities, their dependencies, and the communication paths between the user interface, backend application, business modules, data access layer, database, and external services.

SaludVital follows a modular monolithic architecture. The business modules are organized by responsibility within a single backend application rather than being deployed as independent microservices.

The diagram provides a high-level architectural view. It does not represent individual source files, every class, every database table, or the complete runtime deployment infrastructure.

Component: Web Interface

Technologies represented: Pug, HTML5, Tailwind CSS, and JavaScript.

The Presentation Layer provides the interface through which patients, doctors, and administrators interact with SaludVital.

Its responsibilities include:

• Displaying the application's pages, forms, and dashboards.
• Collecting user input, such as appointment dates and medical specialty selections.
• Presenting operation results, confirmation messages, and validation errors.
• Sending requests to the backend and displaying the responses received.

The presentation layer is responsible for the user experience. Critical business rules and access-control decisions must be enforced by the backend rather than relying exclusively on browser-side validation.

Components: Node.js and Express — Routes and Controllers.

The backend receives requests from the presentation layer and coordinates their processing.

Express routes identify the endpoint associated with a request. Controllers handle the request, invoke the appropriate business functionality, and prepare the HTTP response.

Typical responsibilities include:

• Routing requests to the appropriate controller.
• Coordinating authentication and authorization checks.
• Invoking the business module responsible for the requested operation.
• Returning appropriate success responses or error responses.
• Coordinating access to application services and persistent data.

The backend is the central application boundary between the user interface, business functionality, database, and external integrations.

Component: Security and Request Handling.

Technologies and mechanisms represented: JWT, RBAC, request validation, and error handling.

This component represents the security and request-processing responsibilities of the backend.

Its responsibilities include:

• Authentication: verifying the identity of a user through the configured authentication mechanism.
• JWT: managing JSON Web Tokens when token-based authentication is used.
• RBAC (Role-Based Access Control): enforcing permissions based on assigned roles, such as Patient, Doctor, and Administrator.
• Request validation: checking that incoming data has the expected structure and satisfies applicable validation rules.
• Error handling: managing application errors and returning appropriate responses without unnecessarily exposing sensitive internal information.

Security checks must be applied according to the endpoint and operation. A user being authenticated does not automatically mean that the user is authorized to access every resource.

For example, a patient must not be able to access another patient's private medical information merely by changing an identifier in a request.

The Business Modules group contains the functional areas of SaludVital. These are logical components within the same backend application.

Responsible for user accounts and identity-related operations.

Its scope includes account management, login-related functionality, and user roles. It works with the security mechanisms responsible for authentication and authorization.

Responsible for managing patient profile information and patient-related operations.

It supports the patient information required by appointment scheduling and other authorized clinical workflows.

Responsible for managing doctor information and medical specialties.

It provides the information needed to identify doctors and classify the medical services they provide.

Responsible for representing doctor schedules, availability, and relevant scheduling exceptions.

It provides the information needed to determine whether a requested appointment time is available.

Appointment creation and schedule changes must respect the approved scheduling rules and prevent conflicting bookings.

Responsible for the appointment lifecycle, including scheduling, cancellation, and rescheduling.

Its responsibilities include:

• Validating appointment requests.
• Checking doctor availability.
• Applying the approved appointment policies.
• Maintaining appointment status and relevant history.
• Coordinating persistent changes through the data access layer.

Where concurrent requests could reserve the same time slot, the implementation must enforce the appropriate consistency and concurrency controls. The diagram identifies the component responsible for appointment management but does not specify the complete implementation of those controls.

Responsible for the clinical information associated with medical consultations.

It represents the logical area for consultation records, diagnoses, and prescriptions. Access to this information must be restricted according to the applicable roles and authorization policies.

The component represents these functions at an architectural level; the diagram does not define the full clinical data model.

Responsible for coordinating notifications associated with relevant system events.

Examples include appointment confirmations, reminders, cancellations, and other configured messages.

This component coordinates with the applicable integration component when a notification must be delivered through WhatsApp, email, or SMS.

Notification generation and external delivery are separate responsibilities. A request to send a message does not, by itself, guarantee successful delivery.

Responsible for administrative functionality, reporting-related operations, and recording relevant system actions.

Audit records support traceability by recording applicable information about actions, actors, timestamps, and affected resources according to the project's audit requirements.

Access to administrative functions and audit information must be restricted to authorized users.

Component: Data Access Layer — Sequelize ORM and MySQL2.

The Data Access Layer separates business functionality from the details of database communication.

Sequelize is the Object-Relational Mapper (ORM) used to represent and operate on relational data through application models and queries. MySQL2 provides the database driver used for communication with MySQL.

Responsibilities include:

• Executing database operations requested by business modules.
• Mapping application models to relational database records.
• Reading and persisting application data.
• Supporting transactions where multiple related changes must be handled consistently.
• Handling database-operation errors and propagating them to the appropriate application error-handling mechanisms.

Business modules should use the data access mechanisms consistently rather than duplicating database connection logic across the application.

Component: MySQL Database.

MySQL provides persistent relational storage for the application's information.

The database contains the records defined by the approved database design, including users, roles, patients, doctors, specialties, schedules, appointments, consultations, diagnoses, prescriptions, notifications, and audit information.

Database constraints and relationships help preserve data integrity. Application-level authorization is still required; database access alone does not establish whether a user is permitted to view a particular record.

The diagram represents the database as a single logical persistence component. It does not specify hosting, replication, backup, or deployment topology.

External services are represented separately from the internal backend modules because they are outside the core application's own implementation boundary.

The WhatsApp integration component represents the application's connection to an external WhatsApp provider.

It may support the exchange of messages related to appointment requests, identity verification, confirmations, reminders, and other approved workflows.

The integration component is responsible for coordinating communication with the provider. Provider authentication, webhook processing, delivery-status handling, retries, and idempotency must be implemented according to the selected provider and approved integration design.

The diagram represents an integration point and does not assert that the connection is already operational.

The email integration component represents the connection to an external email delivery provider.

It may be used for configured notifications such as appointment confirmations, reminders, and account-related messages.

The selected provider, credentials, message templates, delivery tracking, and retry policies are implementation details that must be documented and configured separately.

The SMS integration component represents the connection to an external SMS provider.

It may be used to send configured text-message notifications when the relevant provider and application functionality are available.

Provider selection, credentials, costs, delivery status, and retry behavior are outside the scope of this logical component diagram.

The main communication paths represented in the diagram are:

1. Users → Web Interface: users interact with the application through the presentation layer.
2. Web Interface ↔ Express: the frontend sends HTTP/HTTPS requests and receives HTTP responses.
3. Express → Security and Request Handling: incoming requests pass through the applicable security and request-processing mechanisms.
4. Security and Request Handling → Business Modules: requests are routed to the appropriate functional component.
5. Business Modules → Data Access Layer: modules request data retrieval or persistence operations.
6. Data Access Layer ↔ MySQL Database: Sequelize and MySQL2 facilitate database operations and the exchange of query results.
7. Notification Management → Integration Components: the notification module coordinates delivery requests through the configured communication channel.
8. Integration Components ↔ External Providers: the integration components communicate with their respective providers using the supported APIs or protocols.

These arrows describe logical dependencies and communication paths. They do not specify every internal call, the exact execution sequence, or whether a particular operation is synchronous or asynchronous.

SaludVital uses a modular monolithic architecture.

This means that the backend is organized into distinct functional modules while remaining part of one backend application.

The principal characteristics are:

• Separation of responsibilities: each business module focuses on a defined functional area.
• Shared application boundary: the modules belong to the same backend application.
• Centralized data access: modules use the established data access layer to interact with MySQL.
• Internal collaboration: business modules can coordinate through the application's internal interfaces and services.
• Simplified deployment model: the architecture does not require every business module to run as an independent service.

The diagram groups modules for architectural clarity. It does not establish that each module already exists as a separate package or independently deployable component in the source code.

The architecture must support the following principles:

• Enforce authentication and role-based authorization on protected operations.
• Validate incoming requests on the backend.
• Protect sensitive patient and clinical information.
• Preserve relational integrity through appropriate database constraints.
• Apply transactions and concurrency controls to operations that require consistent changes.
• Record relevant administrative and sensitive actions in the audit log.
• Handle external notification failures without incorrectly reporting successful delivery.
• Avoid exposing credentials, tokens, or sensitive internal errors in responses and logs.

These are architectural and implementation requirements. The component diagram identifies where the relevant responsibilities belong but does not prove that every control has already been implemented.

This diagram is a logical software component view.

It documents the principal components and their relationships without attempting to describe:

• Every class, source file, function, or database column.
• The complete physical deployment infrastructure.
• The internal implementation of each business module.
• Provider-specific API endpoints and credentials.
• Detailed sequence diagrams for every use case.
• Infrastructure-level scaling, replication, monitoring, or disaster recovery.

Those topics may be documented separately when required.

The Software Component Diagram provides a shared architectural reference for the SaludVital development team.

It illustrates how the presentation layer, backend, security mechanisms, business modules, data access layer, database, and external integrations fit together within a modular monolithic architecture.

This documentation supports implementation planning, code organization, technical review, maintenance, and future architectural decisions.