El módulo de farmacia cubre los requisitos regulatorios dominicanos para la trazabilidad de medicamentos y la dispensación de sustancias controladas (Lista I-V).
| Documento | Aplica a | Resumen |
|---|---|---|
| Decreto 246-06 Art. 43 | Todos los medicamentos | Obliga a registrar número de lote y fecha de vencimiento en el etiquetado y en los registros internos |
| Decreto 246-06 Art. 105 | Importadores y distribuidores | Trazabilidad de entrada por establecimiento - quién recibió cada lote |
| Ley 50-88 | Psicotrópicos Lista I-V | Registro permanente de dispensaciones disponible para el Ministerio de Salud y la Dirección Nacional de Control de Drogas |
| Decreto 288-96 | Reglamento de Ley 50-88 | Detalla los formatos del registro |
| DIGEMAPS pharmacovigilance | Recalls | El fabricante notifica; la farmacia aísla y reporta el lote afectado |
Marca un producto como Sustancia controlada en su formulario para activar:
serialized - el sistema rechaza cualquier otro modo. Cada unidad lleva su propio número de serie.controlled_substance_log dentro de la misma transacción de la venta. Triggers de PostgreSQL bloquean cualquier UPDATE o DELETE en esa tabla.Ve a Farmacia → Sustancias Controladas para consultar el registro. Filtros disponibles:
El registro es paginado (50 por página, máximo 500). Es la fuente legal de evidencia para auditorías de MISPAS y la Dirección Nacional de Control de Drogas.
| Permiso | Quién | Qué permite |
|---|---|---|
pharmacy.controlled.dispense |
Grupo PHARMACIST |
Dispensar psicotrópicos en el POS |
pharmacy.controlled.audit |
ADMIN, MANAGER, AUDITOR | Leer el registro completo |
ADMIN y MANAGER pueden leer pero no pueden dispensar salvo que estén explícitamente en el grupo PHARMACIST. Esto fuerza separación de funciones (un farmacéutico licenciado autoriza, un cashier opcionalmente cobra).
Cuando DIGEMAPS o el fabricante notifican un recall:
audit_logs y queda asociado al lote).RECALLEDRECALL_WRITEOFF por cada almacén con stock (debita 5.4.1.06 Pérdidas por Recall)audit_logsResultado: el sistema te muestra cuántas transacciones se afectaron y cuántos clientes se notificarán.
| Permiso | Quién |
|---|---|
inventory.batch.recall |
ADMIN, MANAGER |
inventory.batch.writeoff |
ADMIN, ACCOUNTANT |
Por diseño separamos recall (decisión operativa) de writeoff (decisión contable) - un Manager dispara el recall, un Accountant valida la pérdida cuando llega al GL.
El registro del recall queda en audit_logs con entity_type='batches', action='BATCH_RECALL', y un payload JSONB con batch_id, reason, affected_count, y outreach_count. Para reportar:
SELECT created_at, details
FROM audit_logs
WHERE action = 'BATCH_RECALL' AND entity_id = '<batch-id>';
(Una UI de exportación para DIGEMAPS está en el roadmap pero v1 expone los datos via SQL/Postman para auditorías.)
Un workflow durable corre cada día a las 06:00 AST y crea alertas de inventario para todo lote ACTIVE/QUARANTINE que venza en los próximos 30 días (configurable). Las alertas aparecen en Inventario → Alertas con severidad:
El cron también flipea automáticamente lotes ACTIVE cuya fecha de vencimiento ya pasó al estado EXPIRED. Lotes en QUARANTINE no se tocan - la decisión de vencerlos o liberarlos es del farmacéutico.