Recomendaciones

# Recomendaciones de Logic OS

Criterios técnicos y operativos para que el sistema funcione mejor, con riesgos y mitigaciones.
Oferente: Logic OS / Oscar Gabriel Mendoza Celle · RUC 5500120-3
Firmante: Oscar Gabriel Mendoza Celle
Equipo: Diego Laconich · Oscar Celle · Lucas Chamorro
Versión: 3.0 · Propuesta con alternativas cloud, ampliada y servidor interno

# Recomendaciones de Logic OS

Criterios técnicos y operativos para que el sistema funcione mejor, con riesgos y mitigaciones.

## 1. Recomendación general de Logic OS

Recomendación principal de Logic OS: iniciar con infraestructura cloud administrada y arquitectura portable. Esto reduce riesgo de implementación, facilita backups, permite despliegue rápido y mantiene abierta la posibilidad de migrar a servidor interno o Kubernetes en una fase futura.

- Utilizar dominio institucional o subdominio oficial de CRP para confianza pública. El dominio .com.py incluido puede funcionar como redireccionamiento o dominio complementario.
- Separar claramente datos públicos, datos administrativos y métricas anónimas; evitar recolección de diagnósticos, historias clínicas o datos sensibles de usuarios públicos.
- Implementar flujo de validación antes de publicar establecimientos, profesionales, recursos de crisis o documentos técnicos.
- Priorizar usabilidad mobile-first, contraste alto, lenguaje simple y botones visibles para recursos de crisis.
- Entregar código fuente en repositorio CRP y operar mediante ambiente staging antes de producción.

## 2. Recomendaciones por componente

Componente | Recomendación | Justificación
--- | --- | ---
Infraestructura | Iniciar en cloud administrado con Docker. | Reduce dependencias, facilita backups y acelera la puesta en producción.
Dominio | Usar dominio/subdominio institucional CRP como principal y dominio .com.py como apoyo. | Incrementa confianza pública y reduce riesgo de suplantación.
Recursos de crisis | Mantenerlos visibles en todo el portal, pero sin formularios de diagnóstico. | Orientación rápida sin asumir funciones clínicas o de emergencia directa.
Datos de profesionales | Publicar solo datos autorizados y con fecha de actualización. | Cumplimiento de privacidad, exactitud y trazabilidad.
CMS | Aplicar workflow de revisión antes de publicación. | Evita errores en información sensible e institucional.
Analítica | Usar métricas agregadas y anónimas. | Permite medir impacto sin capturar datos sensibles.
Georreferenciación | Validar coordenadas manualmente en casos dudosos. | Una mala ubicación puede afectar la confianza y utilidad del portal.
Contenido | Definir responsables CRP por módulo. | Facilita sostenibilidad posterior a la entrega.

## 3. Cómo podría funcionar mejor el sistema

### Mapa como puerta de entrada

El portal debe facilitar que la ciudadanía encuentre servicios antes que documentos técnicos. Por eso el mapa y la búsqueda cercana deberían estar visibles desde el inicio.

### Crisis siempre visible

El acceso a recursos de crisis debe estar fijo en menú, mobile y footer, con lenguaje claro y enlaces oficiales validados.

### Datos con fecha de verificación

Cada ficha de establecimiento o profesional debería mostrar última actualización, fuente y estado de validación.

### CMS con roles simples

La administración debe ser entendible para usuarios no técnicos: pocos pasos, estados claros y botones de publicación controlados.

## 4. Riesgos y mitigación

Riesgo | Mitigación propuesta
--- | ---
Datos incompletos MSPBS/OPS | Importador con reporte de errores, campos obligatorios, validación y carga por etapas.
Coordenadas incorrectas | Control de calidad geográfico, revisión visual y posibilidad de corrección manual.
Contenido sensible no validado | Flujo de aprobación por CRP antes de publicar.
Dependencia técnica del proveedor | Código fuente en repositorio CRP, documentación, capacitación y arquitectura portable.
Caídas de infraestructura interna | Preferencia por cloud o backups externos si se exige on-premise.