Skip to main content

Overview

OdontologyApp supports multi-location clinic management through the branches system. Each branch represents a physical clinic location where patients are seen, appointments are scheduled, and staff are assigned. Interface Location: /branches
API Endpoint: /api/branches
Source Code: src/routes/branches/+page.svelte
Only users with the MANAGE_BRANCHES permission (admins) can create, edit, or delete branches. All authenticated users can view the branch list.

Database Schema

Branches Table

CREATE TABLE branches (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    address VARCHAR(255),
    icon VARCHAR(50),
    status ENUM('active', 'inactive') DEFAULT 'active',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Field Descriptions

id
integer
Unique branch identifier (auto-generated)
name
string
required
Branch name (e.g., “Sucursal Central”, “Sede Norte”)
address
string
Physical address of the clinic location
icon
string
Emoji or icon representing the branch (defaults to 🏢)
status
enum
Branch operational status: active or inactive
created_at
timestamp
Timestamp when the branch was created

Branch Relationships

Branches are connected to multiple system entities:

User Assignments

Users (admins, doctors, secretaries) can be assigned to a primary branch:
CREATE TABLE users (
    -- ...
    branch_id INT,
    FOREIGN KEY (branch_id) REFERENCES branches(id) ON DELETE SET NULL
);
When a branch is deleted, the ON DELETE SET NULL constraint sets the user’s branch_id to NULL, preventing orphaned references.

Doctor-Branch Association

Doctors can work at multiple locations via the doctor_branches table:
CREATE TABLE doctor_branches (
    doctor_id INT NOT NULL,
    branch_id INT NOT NULL,
    PRIMARY KEY (doctor_id, branch_id),
    FOREIGN KEY (doctor_id) REFERENCES doctors(id) ON DELETE CASCADE,
    FOREIGN KEY (branch_id) REFERENCES branches(id) ON DELETE CASCADE
);
This many-to-many relationship enables:
  • Rotating doctor schedules
  • Multi-location coverage
  • Flexible appointment scheduling

Patient Assignments

Patients are registered at a specific branch:
CREATE TABLE patients (
    -- ...
    branch_id INT,
    FOREIGN KEY (branch_id) REFERENCES branches(id) ON DELETE SET NULL
);

Appointment Tracking

Each appointment is linked to a branch location:
CREATE TABLE appointments (
    -- ...
    branch_id INT NOT NULL,
    FOREIGN KEY (branch_id) REFERENCES branches(id) ON DELETE CASCADE
);
Deleting a branch will cascade delete all appointments scheduled at that location. Consider setting branches to inactive instead.

Creating a Branch

API Request

POST /api/branches
Content-Type: application/json

{
  "name": "Sucursal Norte",
  "address": "Av. Recoleta 456, Santiago",
  "icon": "🏢"
}

Stored Procedure

Branches are created using the sp_create_branch stored procedure:
CALL sp_create_branch(name, address, icon);

Response

{
  "success": true,
  "id": 4
}

Updating a Branch

API Request

PATCH /api/branches
Content-Type: application/json

{
  "id": 2,
  "name": "Sucursal Norte - Renovada",
  "address": "Av. Recoleta 456, Piso 2, Santiago",
  "icon": "🏥",
  "status": "active"
}

Stored Procedure

CALL sp_update_branch(id, name, address, icon, status);

Editable Fields

Name

Branch display name

Address

Physical location address

Icon

Visual identifier (emoji)

Status

Active or inactive

Branch Status

Active Branches

Status: active
  • Appears in branch selection dropdowns
  • Accepts new appointments
  • Users can be assigned
  • Fully operational

Inactive Branches

Status: inactive
  • Hidden from most system views
  • No new appointments can be scheduled
  • Existing data is preserved
  • Can be reactivated later
Use inactive status for temporarily closed locations, renovations, or seasonal operations. This preserves historical data while preventing new activity.

Deleting a Branch

API Request

DELETE /api/branches?id=3

Cascade Effects

Deleting a branch triggers several database operations:
1

Appointment Deletion

All appointments at the branch are permanently deleted (ON DELETE CASCADE)
2

Doctor Assignment Cleanup

All doctor_branches associations are removed
3

User Branch Reset

Users assigned to the branch have their branch_id set to NULL
4

Patient Branch Reset

Patients registered at the branch have their branch_id set to NULL
Deleting a branch is irreversible! All appointments at that location will be permanently lost. Consider using inactive status instead for temporary closures.

Stored Procedure

CALL sp_delete_branch(id);

Branch Selection

Branches are displayed in various system interfaces:

User Session

The logged-in user’s branch is stored in the session:
{
  id: user.id,
  name: user.name,
  branch: user.branch_name || "Todas las sucursales",
  // ...
}
Branches appear in selection dropdowns throughout the system:
  • Patient registration
  • Doctor assignment
  • Appointment scheduling
  • User account creation
<SelectInput
  id="branch-select"
  icon="🏢"
  label="Sucursal"
  bind:value={formData.branch_id}
  options={[
    { value: "", label: "Sin sucursal" },
    ...branches.map(b => ({ value: b.id, label: b.name }))
  ]}
/>

Branch Icons

Branches support emoji icons for visual identification:

Common Icons

IconMeaning
📍Default location marker
🏢Office building
🏥Hospital/clinic
🏪Store/retail location
🌟Flagship/premium location
🏛️Historic/established location
Use consistent icon themes across branches to maintain a professional appearance in the UI.

API Stored Procedures

List Branches

CALL sp_list_branches(include_inactive);
Parameters:
  • include_inactive (boolean): Include inactive branches in results
Example:
CALL sp_list_branches(true);  -- Include inactive branches
CALL sp_list_branches(false); -- Active branches only

Create Branch

CALL sp_create_branch(name, address, icon);
Returns: id of the newly created branch

Update Branch

CALL sp_update_branch(id, name, address, icon, status);

Delete Branch

CALL sp_delete_branch(id);
All stored procedures enforce transactional integrity and handle foreign key constraints automatically.

Permission Requirements

View Branches

Permission: None (all authenticated users)
Roles: Admin, Doctor, Secretary
All users can view the branch list to see available locations.

Manage Branches

Permission: MANAGE_BRANCHES
Roles: Admin only
Only administrators can create, edit, or delete branches.
if (!(await checkPermission(locals, "MANAGE_BRANCHES"))) {
  return forbiddenResponse();
}

Default Test Data

The system includes three test branches:
IDNameAddressIconStatus
1Sucursal CentralAv. Providencia 1234, Santiago📍active
2Sucursal NorteAv. Recoleta 456, Santiago🏢active
3Sucursal SurAv. Gran Av 789, Santiago🏪active

Multi-Branch Workflows

Scenario: Doctor Works at Multiple Locations

Dr. Carlos Soto works at both Central and Norte branches:
INSERT INTO doctor_branches (doctor_id, branch_id) VALUES 
  (1, 1),  -- Central
  (1, 2);  -- Norte
The appointment system can now schedule Dr. Soto at either location.

Scenario: Patient Transfer Between Branches

If a patient moves to a new area, update their branch assignment:
UPDATE patients 
SET branch_id = 3 
WHERE id = 260001;
Historical appointments remain linked to their original branches, while new appointments use the updated location.

Scenario: Temporary Branch Closure

For renovations or temporary closures, set the branch to inactive:
UPDATE branches 
SET status = 'inactive' 
WHERE id = 2;
The branch data is preserved and can be reactivated when operations resume.

Branch Analytics

While not built into the current system, branches enable future analytics:
  • Appointments per location
  • Revenue by branch
  • Patient distribution across locations
  • Doctor utilization by branch
  • Inventory tracking per location
Use the branch_id foreign key on appointments, patients, and other entities to generate location-based reports.

Best Practices

Use clear, descriptive branch names that staff and patients can easily identify (e.g., “Sucursal Norte” instead of “Branch 2”).
Always include full addresses with street number, city, and postal code for patient communications and navigation.
Prefer setting branches to inactive rather than deleting them to preserve historical data and reporting accuracy.
Assign unique icons to each branch for quick visual identification in the UI.
Periodically review branch assignments for users, doctors, and patients to ensure they remain accurate.

Doctor Management

Assigning doctors to branches

User Management

Managing user branch assignments

Appointments

Scheduling appointments at specific branches

Build docs developers (and LLMs) love