# Visión general

Este sistema es el ERP del **Laboratorio Clínico Ximena Caicedo**. Nació como un bot de WhatsApp y creció hasta cubrir la operación diaria del laboratorio: turnos presenciales, toma de muestras, domicilios, órdenes médicas, formularios firmados digitalmente y facturación del día.

## Qué resuelve

| Área | Qué hace el sistema |
|---|---|
| Atención por WhatsApp | Bot que responde, agenda, envía consentimientos y encuestas |
| Turnero presencial | Kiosko, recepción, estaciones de toma de muestras, pantallas de TV |
| Domicilios | Agendamiento y asignación de enfermeros a visitas domiciliarias |
| Formularios | Consentimientos y fichas clínicas firmadas digitalmente |
| Laboratorio | Pacientes, órdenes médicas, exámenes, EPS, empresas, médicos |

## Las tres capas

El código está organizado en tres niveles, de lo más general a lo más específico:

```
erp.php                    punto de entrada único del ERP
  └── core/App.php         arranque, sesión, enrutamiento, control de acceso
        └── modules/<slug>/views/<vista>.php    la pantalla concreta
              └── modules/<slug>/api/*.php      endpoints que consume por fetch
```

Debajo de todo eso están los **servicios** (`services/`), que encapsulan lo que habla con el mundo exterior — sobre todo la API de WhatsApp — y las **clases de dominio** (`classes/lab/`), que concentran las reglas de negocio de pacientes, domicilios, órdenes y formularios.

## Convivencia con el sistema anterior

Hay dos generaciones de código funcionando a la vez, y es intencional:

- **Archivos sueltos en la raíz** (`lab_domicilios.php`, `index.php`, `ver_formulario_enviado.php`, …). Es el sistema original. Siguen siendo el código real de muchas pantallas.
- **Módulos en `modules/`**. Es la estructura nueva. Algunos módulos son pantallas completas (turnero, registro de exámenes); otros son apenas un puente que incluye el archivo viejo.

Un ejemplo de puente, `modules/lab_domicilios/views/index.php`:

```php
require_once APP_ROOT . '/lab_domicilios.php';
```

La migración es gradual y a propósito: mover una pantalla al nuevo esquema no obliga a mover las demás. Al leer el código, **el archivo de la raíz suele ser el que manda**; el módulo solo aporta el registro en el menú y el control de acceso.

## Stack

| Componente | Detalle |
|---|---|
| Lenguaje | PHP 7.4+ (en producción corre sobre versiones más recientes) |
| Base de datos | MariaDB 11.8 |
| Frontend | HTML server-side + JavaScript sin framework; Bootstrap 5 y Font Awesome |
| Mensajería | WhatsApp Cloud API (Meta) |
| IA | Google Gemini Flash — asistente LIA del dashboard del turnero |
| Dependencias | Predis, Monolog, Guzzle, phpdotenv (vía Composer) |

No hay build step ni framework de frontend: las vistas son PHP que emite HTML y el JavaScript va embebido en la misma vista. Es deliberado — mantiene el despliegue en un simple `git pull`.

## Por dónde seguir

- [Enrutamiento y módulos](?m=soporte&v=documentacion&s=arquitectura&d=enrutamiento) — cómo una URL llega a una pantalla
- [Roles y permisos](?m=soporte&v=documentacion&s=arquitectura&d=roles-y-permisos) — quién ve qué
- [Modelo de datos](?m=soporte&v=documentacion&s=arquitectura&d=modelo-de-datos) — las 91 tablas, agrupadas
- [Integración con WhatsApp](?m=soporte&v=documentacion&s=arquitectura&d=whatsapp) — el punto más delicado del sistema