Investigación y valor diferencial
AS²PIRA Health: investigación y evolución con valor
EPINex · 2 de noviembre de 2026 · Edición web local 0.23.0
Conclusión de diseño
El valor de AS²PIRA debe medirse por la continuidad de una atención: información identificada → contexto del paciente → riesgo documentado → responsable y próxima acción → comunicación → respuesta → revisión y resultado documentado. Un tablero bonito o una entrega de WhatsApp no demuestran que se haya solucionado un riesgo. La diferenciación propuesta es reunir esa ruta con las consultas farmacéuticas y permitir comprobar de dónde sale cada dato.
La comparación se hizo con documentación pública oficial. No se modificó Zoho ni se realizó una nueva auditoría de sus configuraciones privadas. Las capacidades comerciales dependen de producto, edición y configuración. No se ha realizado un ensayo comparativo que demuestre superioridad clínica o comercial de AS²PIRA.
Qué aportan los referentes y qué adoptamos
| Referente | Capacidad documentada | Decisión para AS²PIRA | Estado de esta entrega |
|---|---|---|---|
| Zoho Analytics / Forms | Relaciones entre tablas y análisis de información de varios formularios y fuentes | Mantener la identificación explícita; construir una tabla por paciente con variables de distintas fuentes y procedencia por celda | Implementado: cargas CSV revisadas, consultas, filtros, corte de fecha del dato y matrices interactivas |
| Salesforce Health Cloud | Evaluaciones y planes de cuidado con problemas, objetivos y tareas | Convertir un pendiente en una meta documentada, con responsable, fecha y avances conservados | Implementado: metas/acciones y eventos; no equivale al alcance completo del producto Salesforce |
| Healthie | Planes individualizados y seguimiento de objetivos | Mostrar el plan al lado de consultas y respuestas, para dar contexto al seguimiento | Implementado para profesionales; portal y contribución directa del paciente siguen pendientes |
| CareMessage | Comunicación dirigida y flujos que incorporan respuestas | Preparar destinatarios desde una cohorte y diferenciar envío, respuesta reportada y revisión | Preparación de grupos implementada; captura manual de respuestas implementada. Recepción automática por proveedor pendiente |
| Microsoft for Healthcare | Componentes reutilizables y modelo de datos orientado a salud | Separar identidad, consultas, datos externos, casos, acciones y comunicaciones | Separación local implementada; no se instaló ni se depende de Microsoft Cloud |
| HL7 FHIR | Identificadores y procedencia en intercambio de información | Diseñar una futura capa de interoperabilidad conservando identificadores de negocio y trazabilidad | Orientación de arquitectura; sin declarar conformidad FHIR ni conectores hospitalarios operativos |
Fuentes consultadas:
- Zoho: Data blending, relaciones entre tablas, conector de Forms, novedades de Forms.
- Salesforce: Integrated Care Management y modelo de datos.
- Healthie: Care Plans y documentación de planes.
- CareMessage: plataforma.
- Microsoft: construcción de soluciones de salud. Deben revisarse las transiciones de disponibilidad y soporte de sus soluciones; no se tomó como vigente una vista previa retirada.
- HL7: recursos FHIR y procedencia básica US Core STU6. Este último es una guía versionada de referencia, no una certificación de AS²PIRA.
Diferenciadores concretos entregados
1. Paciente 360 con lectura local. Reúne conteos completos del alcance autorizado, consultas recientes por módulo, casos, fuentes externas, metas y respuestas. El resumen redacta información registrada y pendientes documentados; no inventa diagnósticos ni envía información a una IA externa. Los escritos firmados originales permanecen separados e inmutables.
2. Cohortes que se actualizan. Guardan filtros, no listados congelados. Permiten localizar pendientes sin acción activa, casos fuera de fecha, respuestas sin revisión y empeoramiento documentado. El acceso se mantiene por cuenta y vínculo con el paciente.
3. Tablas con semántica explícita. Una fila por paciente, último valor por variable y fecha del dato, sin multiplicar pacientes por un cruce de fuentes. Cada celda ofrece referencia, fecha, estado y huella de origen externo. Los faltantes y los cálculos provisionales no valen cero.
4. Cargas sucesivas a una misma base. Los identificadores de variable permanecen estables; la vista se alimenta de las nuevas cargas publicadas. Los tipos y unidades no se cambian silenciosamente. Las filas originales se conservan con procedencia y deduplicación por contenido.
5. Visualización que conduce al trabajo. Indicadores seleccionables, mapa de atención, ruta anidada de documentación, matriz de intensidad y flujos entre categorías. La celda filtra la tabla de pacientes y desde ella se abre su contexto. La ruta muestra documentación, no eficacia terapéutica.
6. Mensajería con continuidad. Se prepara un grupo de contactos accesibles desde la selección de pacientes. Se mantiene la revisión de contenido, consentimiento, canal y horario de Comunicación programada. No se realiza ningún envío al preparar el grupo. Una respuesta se registra como reportada y requiere valoración profesional independiente.
7. Ayuda en el lugar de decisión. Cada nuevo espacio explica pasos, alcance, límites, denominadores y cómo profundizar. El objetivo es que el usuario pueda comprobar y actuar, no depender de interpretar un gráfico aislado.
Cómo comprobar que mejora el trabajo
| Objetivo | Medición propuesta para piloto | Criterio de aceptación |
|---|---|---|
| Identificar correctamente a una persona | Casos sintéticos de documentos con ceros, tipos diferentes y números coincidentes | Ninguna fusión por nombre o pérdida de ceros; revisión humana de identidad errónea |
| Evitar cifras infladas | Comparar conteo de pacientes y agregados contra una tabla de referencia | Coincidencia exacta en las poblaciones y filtros probados |
| Encontrar qué hacer | Tiempo desde Inicio hasta pendiente, contexto y siguiente acción | Comparar con el proceso actual en usuarios reales; línea base pendiente |
| Cerrar ciclos documentados | Pendientes con responsable/fecha, respuestas revisadas y resultados con evidencia | Indicadores auditables, sin cierre automático por entrega de mensajes |
| Facilitar aprendizaje | Tareas de consulta, filtro, carga y seguimiento sin asistencia | Prueba de usabilidad con profesionales; todavía pendiente |
| Escalar | Latencia, memoria, importación, concurrencia y restauración con carga representativa | Publicar mediciones del equipo y volumen probado; no prometer volumen ilimitado |
Próximas fases de mayor valor
Antes de operación clínica: completar aprobación profesional de fórmulas y reglas provisionales, probar escenarios de extremo a extremo con el equipo, verificar restauración, proveedores de mensajes, consentimiento y manejo de errores. Esta versión no convierte los cálculos pendientes en aprobados.
Integración con respuesta real: configurar proveedores, comprobar entrega y devolución, firmas de webhooks, idempotencia, exclusión de destinatarios y prevención de reenvíos. Falta probarlo con cuentas y destinos autorizados. No se simula que una respuesta capturada manualmente vino de un proveedor.
Calidad de identidad y datos: cola de discrepancias revisable, correcciones con historial, reglas institucionales de calidad y catálogo de significados/unidades. Una unión errónea debe poder rastrearse y corregirse mediante un proceso controlado; hoy no hay fusión masiva automática.
Interoperabilidad: contratos versionados, exportación compatible con un perfil FHIR acordado, terminologías y permisos por institución. No se declara certificación ni se copia un modelo regulatorio extranjero sin revisar su aplicación.
Escala y despliegue futuro: benchmark representativo, respaldo/restauración y concurrencia primero; posteriormente adaptar almacenamiento y trabajos en segundo plano según resultados. Por ahora se mantiene SQLite local, consultas SQL paginadas e índices. No se publica Internet, no se reinician aplicaciones productivas y no se cambia SAmuel ni RADAR en esta entrega.