575 lines
30 KiB
Plaintext
575 lines
30 KiB
Plaintext
================================================================================
|
||
PLAN DE EVOLUCIÓN: BOT WHATSAPP → ERP MULTI-MÓDULO
|
||
Proyecto: Panel de Laboratorio + WhatsApp Bot Manager
|
||
Fecha: Abril 2026
|
||
================================================================================
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
1. ESTADO ACTUAL — QUÉ TENEMOS
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
MÓDULOS YA OPERATIVOS:
|
||
✔ WhatsApp Bot – respuestas automáticas, menús, plantillas Meta
|
||
✔ Conversaciones – bandeja de entrada, operadores asignados
|
||
✔ Mensajes Programados – campañas por fecha/hora
|
||
✔ Pacientes – ficha clínica, historial
|
||
✔ Domicilios – agenda de servicios a domicilio con flujo de estados
|
||
✔ Enfermeras/Personal – portal propio, agenda diaria
|
||
✔ Órdenes Médicas – PDF adjunto, autorización
|
||
✔ Formularios – builder drag-drop, firma digital, enlace público
|
||
✔ Reportes – ingresos, rendimiento de enfermeros, pagos
|
||
✔ Actividad/Auditoría – log de cambios por usuario
|
||
✔ Usuarios & Roles – RBAC completo (roles + role_modules)
|
||
✔ Configuración – tarifas, laboratorio, WhatsApp
|
||
|
||
ARQUITECTURA ACTUAL:
|
||
• Todos los archivos PHP en la raíz del proyecto (lab_*.php, index.php…)
|
||
• API separada en /api/ y /api/lab/
|
||
• Clases en /classes/ y /services/
|
||
• Base de datos: 34 tablas, una sola BD "usite_whatsapp_bot"
|
||
• RBAC: tabla roles + role_modules + SYSTEM_MODULES en config.php
|
||
• Sesiones PHP nativas (login en admin_users)
|
||
|
||
PROBLEMA PRINCIPAL PARA CRECER:
|
||
• Sin sistema de enrutamiento → cada módulo es un archivo suelto en raíz
|
||
• SYSTEM_MODULES hardcodeado en config.php (hay que editarlo cada vez)
|
||
• No hay separación de carpetas por módulo (todo mezclado)
|
||
• Navegación duplicada en cada .php del módulo lab
|
||
• Sin un punto de entrada único (todo camino directo al .php)
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
2. VISIÓN TARGET — ERP MULTI-MÓDULO
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
CONCEPTO:
|
||
Un sistema central con un panel unificado donde cada "módulo" es un paquete
|
||
autocontenido. El core gestiona: autenticación, routing, menú lateral,
|
||
RBAC, notificaciones y eventos. Los módulos se enchufan al core sin
|
||
modificar archivos existentes.
|
||
|
||
MÓDULOS PLANIFICADOS (oleadas):
|
||
|
||
OLEADA 0 – Ya en producción (refactorizar para que usen la nueva estructura)
|
||
- whatsapp_bot → Bot + Conversaciones + Plantillas
|
||
- lab_domicilios → Agenda de domicilios
|
||
- lab_pacientes → Pacientes y fichas
|
||
- lab_formularios → Builder de formularios
|
||
- lab_reportes → Reportes e indicadores
|
||
- lab_ordenes → Órdenes médicas
|
||
- lab_enfermeras → Gestión de personal clínico
|
||
- sistema → Usuarios, Roles, Configuración
|
||
|
||
OLEADA 1 – Nuevos módulos solicitados
|
||
- turnero → Sistema de turnos presenciales en recepción
|
||
|
||
OLEADA 2 – Módulos futuros probables
|
||
- registro_exams → Registro directo de exámenes de laboratorio
|
||
(sin domicilio: paciente llega a la sede)
|
||
- facturacion → Facturación electrónica / DIAN (Colombia)
|
||
- inventario → Reactivos, insumos, stock mínimo
|
||
- citas → Agenda de citas con calendario visual
|
||
- resultados → Entrega digital de resultados (portal paciente)
|
||
- crm_pacientes → Campañas, seguimientos, cohortes
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
3. NUEVA ESTRUCTURA DE CARPETAS
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
/
|
||
├── core/ ← Núcleo del ERP (NO tocar por módulos)
|
||
│ ├── App.php ← Bootstrap, registro de módulos
|
||
│ ├── Router.php ← Enrutador simple (mapea URL→módulo/acción)
|
||
│ ├── Auth.php ← Login/logout/sesión (extraído de config.php)
|
||
│ ├── Rbac.php ← hasModule(), requireModule(), permisos
|
||
│ ├── ModuleRegistry.php ← Catálogo dinámico de módulos instalados
|
||
│ ├── Layout.php ← Renderiza sidebar, navbar, footer
|
||
│ └── Helpers.php ← Funciones globales (esc, jsonOk, etc.)
|
||
│
|
||
├── modules/ ← Un subdirectorio por módulo
|
||
│ ├── whatsapp_bot/
|
||
│ │ ├── module.php ← Descriptor: nombre, slug, icono, permisos
|
||
│ │ ├── views/ ← Las páginas (ex lab_*.php migradas)
|
||
│ │ └── api/ ← Endpoints REST propios del módulo
|
||
│ │
|
||
│ ├── domicilios/
|
||
│ │ ├── module.php
|
||
│ │ ├── views/
|
||
│ │ └── api/
|
||
│ │
|
||
│ ├── turnero/ ← NUEVO ★ (Oleada 1)
|
||
│ │ ├── module.php
|
||
│ │ ├── views/
|
||
│ │ │ ├── dashboard.php ← Pantalla administrador
|
||
│ │ │ ├── display.php ← Pantalla TV/recepción (sin login)
|
||
│ │ │ └── kiosko.php ← Pantalla táctil toma de turno
|
||
│ │ └── api/
|
||
│ │ ├── create_turno.php
|
||
│ │ ├── llamar_turno.php
|
||
│ │ ├── get_estado.php
|
||
│ │ └── sse_turno.php ← Server-Sent Events para la pantalla TV
|
||
│ │
|
||
│ ├── registro_exams/ ← PENDIENTE — Oleada 2
|
||
│ │ ├── module.php
|
||
│ │ ├── views/
|
||
│ │ │ ├── registrar.php
|
||
│ │ │ ├── lista.php
|
||
│ │ │ └── detalle.php
|
||
│ │ └── api/
|
||
│ │ ├── save_examen.php
|
||
│ │ ├── get_examenes.php
|
||
│ │ ├── cambiar_estado.php
|
||
│ │ └── imprimir_etiqueta.php
|
||
│ │
|
||
│ └── sistema/
|
||
│ ├── module.php
|
||
│ ├── views/
|
||
│ │ ├── usuarios.php ← lab_usuarios.php migrado
|
||
│ │ └── configuracion.php
|
||
│ └── api/
|
||
│
|
||
├── shared/ ← Componentes reutilizables entre módulos
|
||
│ ├── components/
|
||
│ │ ├── sidebar.php ← Menú lateral dinámico (según módulos del rol)
|
||
│ │ ├── navbar.php
|
||
│ │ ├── page_header.php
|
||
│ │ └── modal_confirm.php
|
||
│ └── js/
|
||
│ ├── erp-core.js ← fetch wrapper, toasts, eventos globales
|
||
│ └── erp-table.js ← Tablas con filtro, paginación, export
|
||
│
|
||
├── classes/ ← (ya existe, mantener)
|
||
├── services/ ← (ya existe, mantener)
|
||
├── api/ ← API global (ya existe, mantener para bot)
|
||
├── config/
|
||
│ └── config.php ← Simplificado: SOLO BD y constantes base
|
||
│
|
||
├── public/ ← (opcional futuro) assets compilados
|
||
│ └── assets/
|
||
│
|
||
└── index.php ← Punto de entrada único → instancia App.php
|
||
|
||
|
||
NOTA SOBRE MIGRACIÓN SIN ROMPER NADA:
|
||
Los archivos lab_*.php actuales permanecen en raíz mientras se migran.
|
||
Se crea un alias: cada modules/X/views/Y.php incluye el legacy si aún no
|
||
se ha reescrito. No hay "big bang rewrite".
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
4. SISTEMA DE ROLES Y PERMISOS (RBAC EXPANDIDO)
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
MODELO ACTUAL:
|
||
roles (id, name, slug, color, is_system)
|
||
└── role_modules (role_id, module_slug) ← solo read/write implícito
|
||
|
||
MODELO PROPUESTO — RBAC con acciones:
|
||
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ roles │
|
||
│ id | name | slug | description | color | is_system │
|
||
└──────────────────┬──────────────────────────────────────────┘
|
||
│ 1:N
|
||
┌──────────────────▼──────────────────────────────────────────┐
|
||
│ role_permissions (reemplaza role_modules con más granularidad)
|
||
│ id | role_id | module_slug | can_view | can_create │
|
||
│ can_edit | can_delete | can_export | extra_json │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
|
||
extra_json ejemplos:
|
||
turnero → {"puede_llamar": true, "puede_reasignar": false}
|
||
reportes → {"rango_max_dias": 90}
|
||
whatsapp → {"puede_broadcast": true}
|
||
|
||
ROLES DEL SISTEMA A DEFINIR:
|
||
|
||
Slug Nombre Descripción
|
||
─────────────────────────────────────────────────────────────────
|
||
superadmin Super Admin Acceso total, configura el sistema
|
||
admin Administrador Acceso total sin configuración técnica
|
||
recepcionista Recepcionista Turnero + Pacientes (Oleada 1)
|
||
bacteriologo Bacteriólogo Registro exámenes + Resultados (Oleada 2)
|
||
enfermero Enfermero Portal domicilios (ya existe)
|
||
supervisor Supervisor Reportes + sin acceso a config
|
||
operador_bot Operador WhatsApp Solo bandeja de conversaciones
|
||
readonly Solo lectura Ver dashboards sin editar
|
||
|
||
REGLA: is_system=1 en superadmin y admin → no se pueden borrar.
|
||
Los demás roles son personalizables por el cliente.
|
||
|
||
FLUJO DE VERIFICACIÓN EN UNA VISTA:
|
||
1. ¿Está logueado? → sino → login
|
||
2. ¿El rol tiene module_slug? → sino → 403 sin módulo
|
||
3. ¿La acción requiere can_edit? → verificar permiso específico
|
||
4. ¿Hay restricción extra_json? → verificar campo relevante
|
||
|
||
HELPER PROPUESTO (core/Rbac.php):
|
||
hasModule($slug) → bool (ya existe en helpers)
|
||
canDo($slug, $action) → bool (nuevo, $action = view/create/edit/delete/export)
|
||
requireAction($slug, $action) → lanza 403 si no tiene permiso
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
5. MÓDULO TURNERO — DISEÑO DETALLADO
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
CONCEPTO:
|
||
Sistema de turnos para pacientes que llegan presencialmente a la sede.
|
||
Tres pantallas distintas:
|
||
A) Kiosko (tablet/touch en recepción) → el paciente toma su turno
|
||
B) TV/Display (pantalla grande) → muestra turno actual + cola
|
||
C) Dashboard admin → el operador llama turnos, gestiona
|
||
|
||
TABLAS BD NUEVAS:
|
||
|
||
turnero_servicios
|
||
id, nombre, prefijo (ej. "A"), color, tiempo_estimado_min, activo
|
||
|
||
turnero_sesiones
|
||
id, fecha, abierto_por INT FK admin_users, cerrado_por, inicio_at, fin_at
|
||
(una sesión = un día de atención)
|
||
|
||
turnero_turnos
|
||
id, sesion_id,
|
||
numero INT, ← número correlativo de la sesión
|
||
codigo VARCHAR(10), ← "A001", "B012"
|
||
servicio_id,
|
||
paciente_nombre VARCHAR(150),
|
||
paciente_cel VARCHAR(20),
|
||
estado ENUM(espera, llamado, en_atencion, atendido, ausente, cancelado),
|
||
modulo_atencion INT, ← puesto/ventanilla que atiende
|
||
llamado_at, inicio_at, fin_at, creado_at
|
||
|
||
turnero_modulos
|
||
id, nombre (ej. "Ventanilla 1"), activo, usuario_actual INT FK admin_users
|
||
|
||
FLUJO:
|
||
1. Recepcionista / kiosko crea turno → estado "espera"
|
||
2. Operador en dashboard hace clic "Llamar siguiente"
|
||
→ estado "llamado", pantalla TV muestra "A-001 → Ventanilla 2"
|
||
→ (opcional) SMS/WhatsApp al paciente con su turno
|
||
3. El paciente llega → operador pasa a "en_atención"
|
||
4. Al terminar → "atendido"
|
||
5. Si no aparece → "ausente" (puede regresar al final de la cola)
|
||
|
||
PANTALLA TV (display.php):
|
||
• Sin login
|
||
• Se actualiza por SSE (Server-Sent Events) cada vez que se llama un turno
|
||
• Muestra: turno actual por cada ventanilla + próximos 5 en espera
|
||
• Diseño visual grande, colores por servicio
|
||
|
||
INTEGRACIÓN CON WHATSAPP (OPCIONAL):
|
||
Cuando se llama el turno → enviar mensaje al paciente si dejó celular
|
||
Usar WhatsAppService ya existente.
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
6. MÓDULO REGISTRO DE EXÁMENES — DISEÑO DETALLADO [OLEADA 2 — pendiente]
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
CONCEPTO:
|
||
Registrar exámenes de análisis clínico cuando el paciente llega a la sede
|
||
(a diferencia de lab_domicilios que es a domicilio).
|
||
Incluye: recepción de muestra, trazabilidad, estado de procesamiento,
|
||
y eventualmente entrega de resultados.
|
||
|
||
TABLAS BD NUEVAS:
|
||
|
||
exam_tipos
|
||
id, codigo (ej. "HEM", "GLU"), nombre, categoria, precio_base,
|
||
requiere_ayunas TINYINT, instrucciones TEXT, activo
|
||
|
||
exam_ordenes (la "orden de trabajo" del laboratorio)
|
||
id, paciente_id FK lab_pacientes,
|
||
numero_orden VARCHAR(20) UNIQUE, ← ej. "ORD-2026-00123"
|
||
origen ENUM(presencial, domicilio, whatsapp, referido),
|
||
medico_remitente VARCHAR(150),
|
||
entidad_pagadora VARCHAR(150),
|
||
tipo_pago ENUM(particular, eps, convenio),
|
||
total_cobrado DECIMAL(10,2),
|
||
estado ENUM(pendiente, en_proceso, parcial, completado, entregado, anulado),
|
||
observaciones TEXT,
|
||
recibido_por INT FK admin_users,
|
||
creado_at, actualizado_at
|
||
|
||
exam_items (los exámenes individuales dentro de una orden)
|
||
id, orden_id FK exam_ordenes,
|
||
tipo_id FK exam_tipos,
|
||
estado ENUM(pendiente, muestra_tomada, en_analisis, resultado_listo, entregado),
|
||
muestra_tipo VARCHAR(50), ← sangre, orina, hisopado...
|
||
muestra_recibida_at,
|
||
resultado TEXT,
|
||
resultado_pdf VARCHAR(300),
|
||
procesado_por INT FK admin_users,
|
||
entregado_at
|
||
|
||
exam_etiquetas (para imprimir en los tubos)
|
||
id, item_id FK exam_items,
|
||
codigo_barras VARCHAR(50) UNIQUE,
|
||
impreso_at, impreso_por INT FK admin_users
|
||
|
||
FLUJO:
|
||
1. Recepcionista busca/crea paciente (reutiliza lab_pacientes)
|
||
2. Crea orden → agrega exámenes de la lista exam_tipos
|
||
3. Sistema genera número de orden y código de barras por tubo
|
||
4. Se imprime etiqueta (ZPL o PDF)
|
||
5. Bacteriólogo cambia estado → en_análisis → resultado_listo
|
||
6. Administrador entrega resultados (descarga PDF / enlace portal)
|
||
|
||
RELACIÓN CON MÓDULOS EXISTENTES:
|
||
• Paciente → usa lab_pacientes (ya existe)
|
||
• Si viene de un domicilio → exam_ordenes.origen = 'domicilio',
|
||
vincular con lab_domicilios (campo opcional domicilio_id)
|
||
• Si tiene orden médica adjunta → vincular con lab_ordenes_medicas
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
7. BASE DE DATOS — PLAN DE MIGRACIONES
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
REGLA: todas las migraciones son ADITIVAS (ALTER ADD, CREATE TABLE).
|
||
NUNCA DROP COLUMN ni RENAME en producción sin respaldo previo.
|
||
|
||
Migración 001 – RBAC expandido
|
||
ALTER TABLE role_modules ADD COLUMN can_view TINYINT(1) DEFAULT 1;
|
||
ALTER TABLE role_modules ADD COLUMN can_create TINYINT(1) DEFAULT 0;
|
||
ALTER TABLE role_modules ADD COLUMN can_edit TINYINT(1) DEFAULT 0;
|
||
ALTER TABLE role_modules ADD COLUMN can_delete TINYINT(1) DEFAULT 0;
|
||
ALTER TABLE role_modules ADD COLUMN can_export TINYINT(1) DEFAULT 0;
|
||
ALTER TABLE role_modules ADD COLUMN extra_json JSON NULL;
|
||
RENAME TABLE role_modules TO role_permissions; ← (o alias)
|
||
|
||
Migración 002 – Nuevos roles
|
||
INSERT INTO roles (name, slug, description, color, is_system) VALUES
|
||
('Super Admin', 'superadmin', 'Acceso total al sistema', '#dc3545', 1),
|
||
('Recepcionista', 'recepcionista', 'Turnero y recepción de muestras', '#198754', 0),
|
||
('Bacteriólogo', 'bacteriologo', 'Análisis y resultados', '#0dcaf0', 0),
|
||
('Supervisor', 'supervisor', 'Solo reportes y consultas', '#fd7e14', 0),
|
||
('Operador Bot', 'operador_bot', 'Gestión de conversaciones', '#6f42c1', 0);
|
||
|
||
Migración 003 – Turnero [Oleada 1]
|
||
CREATE TABLE turnero_servicios (...)
|
||
CREATE TABLE turnero_sesiones (...)
|
||
CREATE TABLE turnero_turnos (...)
|
||
CREATE TABLE turnero_modulos (...)
|
||
|
||
Migración 004 – SYSTEM_MODULES dinámica (mover de config.php a BD) [Oleada 1]
|
||
CREATE TABLE system_modules (
|
||
slug VARCHAR(100) PK,
|
||
name VARCHAR(150),
|
||
icon VARCHAR(50), ← "fas fa-vials"
|
||
category VARCHAR(50), ← "lab", "bot", "sistema", "clinico"
|
||
route VARCHAR(200), ← URL base del módulo
|
||
is_active TINYINT(1),
|
||
sort_order INT,
|
||
created_at TIMESTAMP
|
||
)
|
||
|
||
Poblar con los módulos actuales + turnero.
|
||
registro_exams se agrega en Migración 005 (Oleada 2).
|
||
config.php mantiene el array como fallback hasta que la BD esté lista.
|
||
|
||
Migración 005 – Registro de exámenes [Oleada 2]
|
||
CREATE TABLE exam_tipos (...)
|
||
CREATE TABLE exam_ordenes (...)
|
||
CREATE TABLE exam_items (...)
|
||
CREATE TABLE exam_etiquetas(...)
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
8. ROUTER Y PUNTO DE ENTRADA
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
OPCIÓN RECOMENDADA (sin framework, compatible con estructura actual):
|
||
|
||
index.php → incluye core/App.php
|
||
App.php → lee $_GET['m'] (módulo) y $_GET['v'] (vista)
|
||
→ verifica sesión + permisos via Rbac.php
|
||
→ incluye modules/{m}/views/{v}.php
|
||
→ si no existe → 404 amigable
|
||
|
||
URLS LIMPIAS con .htaccess:
|
||
/turnero/dashboard → ?m=turnero&v=dashboard
|
||
/turnero/display → ?m=turnero&v=display (sin login)
|
||
/lab/domicilios → ?m=domicilios&v=index
|
||
/lab/pacientes → ?m=lab_pacientes&v=index
|
||
|
||
.htaccess ya existe en el proyecto → solo agregar RewriteRules.
|
||
|
||
COMPATIBILIDAD:
|
||
Los lab_*.php en raíz siguen funcionando directamente.
|
||
El router añade una capa adicional, no reemplaza lo existente.
|
||
Migración gradual: mover módulos uno a uno al nuevo sistema.
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
9. LAYOUT Y NAVEGACIÓN UNIFICADA
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
PROBLEMA ACTUAL:
|
||
Cada lab_*.php repite el mismo sidebar a mano (>50 líneas duplicadas).
|
||
Si se agrega un módulo hay que editar todos los archivos.
|
||
|
||
SOLUCIÓN:
|
||
shared/components/sidebar.php → se genera dinámicamente desde:
|
||
1. La tabla system_modules (activos)
|
||
2. Filtrado por los módulos que tiene el rol del usuario logueado
|
||
3. Agrupados por "category" (Bot, Laboratorio, Clínico, Sistema)
|
||
|
||
Cada layout nueva vista incluye:
|
||
<?php include APP_ROOT . '/shared/components/sidebar.php'; ?>
|
||
|
||
El sidebar detecta la URL activa y resalta el elemento correspondiente.
|
||
|
||
GRUPOS DEL MENÚ LATERAL:
|
||
🤖 WhatsApp
|
||
Conversaciones | Bot & Menús | Plantillas | Programados
|
||
🏥 Laboratorio
|
||
Dashboard | Domicilios | Pacientes | Enfermeras | Órdenes
|
||
🧪 Clínico (Oleada 2)
|
||
Registro Exámenes | Resultados
|
||
🎟️ Turnero (Oleada 1)
|
||
Dashboard | Configurar Servicios
|
||
📊 Reportes
|
||
Ingresos | Rendimiento | Exportar
|
||
⚙️ Sistema
|
||
Usuarios & Roles | Configuración | Actividad
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
10. PLAN DE IMPLEMENTACIÓN — FASES
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
── BASE DEL SISTEMA ─────────────────────────────────────────────────────────
|
||
|
||
FASE 0 – Preparación (1-2 días) [SIN impacto en producción] ✅ COMPLETADA
|
||
✓ Crear carpetas: core/, modules/, shared/
|
||
✓ Extraer Auth.php y Rbac.php desde config.php y _helpers.php
|
||
✓ Crear shared/components/sidebar.php unificado
|
||
✓ Migración 001: expandir role_permissions (columnas can_*)
|
||
✓ Migración 002: insertar nuevos roles
|
||
✓ Agregar nuevos slugs a SYSTEM_MODULES en config.php
|
||
|
||
FASE 1 – Core: Router y estructura modular (1 semana) ✅ COMPLETADA
|
||
✓ Crear core/Router.php y core/App.php
|
||
✓ Crear core/Layout.php, core/Helpers.php (core/Rbac.php ya existía de FASE 0)
|
||
✓ Punto de entrada erp.php (coexiste con index.php legacy)
|
||
✓ Activar .htaccess con URLs limpias (/modulo/vista → erp.php?m=&v=)
|
||
✓ Mover módulos existentes a modules/ (module.php + views/index.php stubs para 11 módulos)
|
||
|
||
FASE 2 – SYSTEM_MODULES dinámica (2 días) ✅ COMPLETADA
|
||
✓ Migración 004: tabla system_modules (con INSERT IGNORE, oleada, sort_order)
|
||
✓ core/ModuleRegistry.php: lee BD → module.php → SYSTEM_MODULES (fallback en cascada)
|
||
✓ Sidebar lee desde ModuleRegistry en lugar de config.php (dinámico por categoría)
|
||
✓ Interfaz /erp.php?m=usuarios&v=modulos (toggle activo + sort_order)
|
||
|
||
── MÓDULOS NUEVOS ────────────────────────────────────────────────────────────
|
||
|
||
FASE 3 – Turnero MVP — Oleada 1 (3-5 días)
|
||
□ Migración 003: tablas turnero_*
|
||
□ modules/turnero/module.php + views/ + api/
|
||
□ Pantalla kiosko (toma turno, sin login)
|
||
□ Pantalla display TV (SSE, sin login)
|
||
□ Dashboard admin (llamar, gestionar)
|
||
□ Registrar slug turnero en system_modules
|
||
|
||
FASE 4 – Oleada 2 (Registro de Exámenes + futuros)
|
||
□ Migración 005: tablas exam_*
|
||
□ Catálogo de tipos de examen (CRUD admin)
|
||
□ Flujo de recepción: buscar paciente → crear orden → agregar ítems
|
||
□ Vista bacteriólogo: lista del día, cambiar estados
|
||
□ Impresión de etiquetas (PDF A6)
|
||
□ Conectar con lab_pacientes (reutilizar buscador existente)
|
||
□ Facturación, Inventario, CRM, Portal Paciente…
|
||
□ API pública con tokens (para integraciones)
|
||
□ App móvil (portal enfermero actual → Progressive Web App)
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
11. CONVENCIONES TÉCNICAS A SEGUIR
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
NOMENCLATURA:
|
||
• Tablas BD: snake_case, prefijadas por módulo (turnero_, exam_, lab_)
|
||
• Archivos PHP: snake_case (save_turno.php, get_examenes.php)
|
||
• Clases PHP: PascalCase (TurneroService.php, ExamOrder.php)
|
||
• Slugs: siempre lowercase con guiones (turnero, registro-exams)
|
||
• API endpoints: REST-ish, verbos en el nombre (get_, save_, delete_)
|
||
|
||
SEGURIDAD:
|
||
• Toda API: requireMethod() + verificar sesión + verificar permiso
|
||
• Parámetros: siempre sanitizar y tipificar antes de usar en SQL
|
||
• Queries: siempre PDO preparado (ya implementado en Database.php)
|
||
• Pantallas sin login (kiosko, display): NUNCA exponer datos sensibles,
|
||
solo número de turno y servicio.
|
||
• Subida de archivos: misma lógica de /upload.php (validar MIME + ext)
|
||
• CSRF: para formularios de mutación, incluir token en sesión
|
||
|
||
ESTILO DE CÓDIGO:
|
||
• Frontend: Bootstrap 5 + Font Awesome 6 (ya en uso, mantener)
|
||
• Sin jQuery nuevo; usar fetch() nativo (ya en uso)
|
||
• Toasts de notificación: usar patrón ya existente en index.php
|
||
• Responsive: mobile-first (portal enfermero se usa desde celular)
|
||
|
||
API RESPONSE FORMAT (ya establecido, mantener):
|
||
Éxito: { "ok": true, "data": {...}, "message": "..." }
|
||
Error: { "ok": false, "error": "...", "code": 4XX }
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
12. DECISIONES CLAVE A CONFIRMAR CON EL CLIENTE
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
1. ¿El turnero es para UNA sede o múltiples sedes?
|
||
(Multi-sede requiere añadir sede_id a las tablas)
|
||
|
||
2. ¿Facturación electrónica (DIAN) es obligatorio desde el inicio
|
||
o puede dejarse para Oleada 2?
|
||
|
||
3. ¿El portal de entrega de resultados es para los pacientes directamente
|
||
(requiere login/token para pacientes) o solo descarga interna?
|
||
|
||
4. ¿Se quiere app móvil nativa o es suficiente con PWA/responsive?
|
||
|
||
5. ¿Los exámenes tienen que integrar con algún analizador automático
|
||
(interfaz LIS) o el resultado se digita manual?
|
||
|
||
6. ¿El turno se puede tomar ANTES de llegar (turno virtual por WhatsApp)?
|
||
Esto conecta el módulo Turnero con el Bot.
|
||
|
||
7. ¿El sistema será multi-tenant (varios laboratorios/clientes en el mismo
|
||
servidor) o siempre una instalación por cliente?
|
||
|
||
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
13. RESUMEN EJECUTIVO
|
||
────────────────────────────────────────────────────────────────────────────────
|
||
|
||
Lo que TENEMOS es una base sólida:
|
||
✓ BD bien estructurada con 34 tablas
|
||
✓ RBAC funcional (roles + módulos)
|
||
✓ API consistente con helpers reutilizables
|
||
✓ Autenticación robusta con bcrypt
|
||
✓ Integración WhatsApp activa
|
||
✓ Módulos de laboratorio maduros
|
||
|
||
Lo que HAY QUE CONSTRUIR para el ERP:
|
||
→ Estructura de carpetas por módulo (core/ + modules/)
|
||
→ Router centralizado y sidebar dinámico
|
||
→ RBAC con granularidad de acciones (can_view/create/edit/delete/export)
|
||
→ Módulo Turnero — Oleada 1 (3-5 días)
|
||
→ SYSTEM_MODULES en BD (en lugar de hardcoded en config.php)
|
||
→ Módulo Registro de Exámenes — Oleada 2 (5-7 días, pendiente)
|
||
|
||
Estrategia: EVOLUCIÓN INCREMENTAL, no reescritura.
|
||
El sistema sigue funcionando en producción mientras se construyen
|
||
los nuevos módulos en paralelo. Solo se migra lo viejo al nuevo
|
||
sistema cuando el nuevo está validado y estable.
|
||
|
||
================================================================================
|
||
Documento preparado por GitHub Copilot — Abril 2026
|
||
Próxima revisión: tras confirmar decisiones de la sección 12
|
||
================================================================================
|