Si usted ha participado en la evaluación, selección o desarrollo de software para el sector salud, es muy probable que haya sido testigo directo de esta paradoja:
Se invierten meses de trabajo, licitaciones exhaustivas o miles de líneas de código para implementar una nueva Historia Clínica Electrónica (EHR), un sistema de gestión hospitalaria (HIS) o un módulo predictivo con algoritmos de última generación. En el papel o en la demo comercial, todo parecía impecable: “trazabilidad total, arquitectura moderna y eficiencia sin precedentes”.
Poco tiempo después de entrar a producción en los pasillos de la clínica, la realidad choca contra un muro:
- Los médicos especialistas afirman que el sistema “es un obstáculo que les roba tiempo valioso frente al paciente”.
- El personal de enfermería en urgencias recurre a cuadernos y hojas sueltas para registrar signos vitales antes de transcribirlos mecánicamente al sistema.
- Se multiplican las notas clínicas incompletas, se disparan las glosas de facturación por inconsistencias y los profesionales asistenciales acusan a la pantalla como el principal detonante de su agotamiento laboral (burnout).
La explicación recurrente en muchas reuniones técnicas suele ser rápida y cómoda: “Los médicos son difíciles; se resisten al cambio cultural”.
Lo que normalmente sucede es que esa afirmación es un mito que encubre fallas de ingeniería.
A lo largo de más de una década investigando, desarrollando y auditando sistemas de información clínica e inteligencia artificial en hospitales e instituciones académicas, jamás he conocido a un médico o enfermera que rechace una herramienta que genuinamente le ayude a tomar mejores decisiones, a reducir la incertidumbre diagnóstica o a terminar sus labores a tiempo o antes.
Lo que el clínico rechaza no es la tecnología: es el software que introduce fricción innecesaria, que ignora el flujo cognitivo del acto médico y que fue construido a espaldas de la realidad asistencial. Esta es la historia de la mayoría de sistemas de información, donde la prioridad es dar respuesta adminsitrativa, legal, comercial, etc, antes de dar soporte al flujo asistencial.
Hoy, cuando la Inteligencia Artificial generativa y los agentes de codificación autónoma prometen acelerar el desarrollo de software a velocidades nunca vistas, el riesgo de multiplicar este fracaso es gigantesco. Si permitimos que el desarrollo de software clínico se guíe por la improvisación y los prompts sueltos (lo que hoy llamamos vibe coding), inundaremos los hospitales de herramientas estocásticas, frágiles y potencialmente peligrosas.
Esta guía está dirigida a quienes tienen la responsabilidad de construir y evaluar la tecnología en salud: evaluadores de tecnología sanitaria (ETS), líderes de informática médica, arquitectos de software y desarrolladores. En ella explico los tres vacíos que condenan al software clínico y cómo gobernar su desarrollo mediante una trilogía metodológica: CRISP-DM, el Marco TURF y Spec-Driven Development (SDD). Metodologías con las cuales he interactuado en mi carrera profesional y que las veo como instrumentos complementarios y valiosos.
1. El Diagnóstico: ¿Por qué fracasan las soluciones clínicas?
Para evaluar o programar software en salud con rigor, primero debemos comprender las tres dimensiones donde colapsan la mayoría de los proyectos:
NIVELES DE FALLA EN SOFTWARE DE SALUD
| Falla de Negocio y Datos (Desconexión con el flujo) | Se construye la solución técnica correcta para el problema clínico equivocado. |
| Falla Cognitiva | Se ignora la sobrecarga mental del clínico; el software crea “tareas parásitas”. |
| Falla de Ejecución Técnica (Ambigüedad de Requisitos) | Código improvisado (Vibe Coding) |
- La desconexión entre el algoritmo y el problema Real: Equipos de datos o proveedores desarrollan modelos con métricas técnicas deslumbrantes (ej. AUC-ROC de 0.94 para predicción de sepsis) que nunca salvan una vida porque nadie definió cómo encajan en el flujo de trabajo asistencial o en qué momento de la atención el médico puede actuar sobre esa predicción.
- El desprecio de la usabilidad cognitiva: Tratar la usabilidad como si fuera un asunto puramente cosmético (“hacer botones más bonitos”). En salud, una mala interfaz traslada el cálculo mental al médico exhausto, dispara la fatiga de alarmas (alert fatigue) y genera errores asistenciales.
- La trampa del Vibe Coding con IA: Con la llegada de los LLMs, muchos desarrolladores han abandonado la documentación y la especificación previa, confiando en que el modelo “entienda la vibra” de lo que se necesita. En aplicaciones recreativas un error es un bug menor; en salud, el código generado sin especificaciones deterministas puede alterar el cálculo de una infusión o mezclar historiales clínicos.
2. La trilogía de gobernanza: Del negocio al código
Para superar estos tres niveles de falla, el desarrollo y la evaluación de tecnología en salud deben estructurarse en una cadena disciplinada:
flowchart TD
subgraph Capa1["1. CRISP-DM: Alineación de Negocio & Datos"]
C1["¿Qué decisión médica o KPI asistencial resolvemos?"]
C2["Corte vertical ágil: valor clínico funcional en semanas"]
end
subgraph Capa2["2. MARCO TURF: Ingeniería Cognitiva & Ontología"]
T1["U (User): Sobrecarga mental, fatiga y turnos clínicos"]
T2["F (Function): Metas y operaciones del dominio médico"]
T3["R (Representation): Trasladar cálculo mental a percepción visual"]
T4["T (Task): Erradicación de tareas parásitas"]
end
subgraph Capa3["3. SPEC-DRIVEN DEVELOPMENT (SDD): Ejecución con IA"]
S1["docs/constitution.md: Leyes inmutables y estándares (FHIR/OMOP)"]
S2["specs/spec.md: Requisitos en notación EARS formal"]
S3["TDD Asistido por IA: Pruebas unitarias ANTES de la implementación"]
end
Capa1 --> Capa2
Capa2 --> Capa3CRISP-DM: Entendimiento del Problema Antes de Teclear
Publicada en 1999 por un consorcio industrial y vigente como el estándar más adoptado en ciencia de datos, CRISP-DM (CRoss Industry Standard Process for Data Mining) enseña un principio innegociable:
“La causa número uno de fracaso no es la falta de datos ni la complejidad del algoritmo: es construir el modelo correcto para el problema equivocado.”
Para el Evaluador de Tecnología:
- Exija el caso de uso antes del algoritmo: No apruebe proyectos justificados con frases como “vamos a aplicar analítica a las historias clínicas”. Exija la Fase I (Business Understanding): ¿Cuál es el desenlace clínico que se quiere mejorar?, ¿Cuál es la tasa aceptable de falsos positivos en el servicio de urgencias?, ¿Cuál es el costo asistencial de una falsa alarma?
- Audite el corte del trabajo: Rechace esquemas en cascada (waterfall) donde el equipo pasa 8 meses limpiando datos sin entregar valor tangible. Exija cortes verticales ágiles: pipelines funcionales de punta a punta desplegados en iteraciones de 3 a 4 semanas.
Para el Desarrollador:
- Antes de abrir un notebook o escribir un endpoint, documente un canvas de viabilidad (
docs/canvas.md). Si no puede explicar en un solo párrafo qué decisión clínica habilita su código, aún no está listo para programar.
El Marco TURF: La usabilidad como propiedad científica
El mayor cuello de botella en los sistemas de información en salud no es algorítmico, sino de interacción cognitiva.
El estándar que he trabajado en esta materia es el Marco TURF (Task, User, Representation, Function), formulado por el Dr. Jiajie Zhang y el Dr. Muhammad Walji en el Centro Nacional de Apoyo Cognitivo en Salud de EE.UU. (NCCD / UTHealth), y compilado en el libro Better EHR.
TURF define formalmente que la usabilidad en salud se compone de tres pilares inseparables:
- Útil (Useful): ¿El sistema soporta el trabajo clínico real? Evalúa si las funciones del software cubren las metas médicas intrínsecas (pilar Function).
- Usable (Usable): ¿Es eficiente, fácil de aprender y tolerante a fallos humanos? Un sistema usable minimiza los pasos cognitivos y protege al paciente ante el error del usuario bajo estrés.
- Satisfactorio (Satisfying): La percepción subjetiva del clínico. Si el médico siente rechazo o frustración cada vez que interactúa con el sistema, por definición científica el sistema NO es usable, lo que inevitablemente derivará en sabotaje del dato, notas clonadas (copy-paste) y riesgos de seguridad.
graph TD
%% Definición de los nodos con su texto correspondiente
F["FUNCTION (F)<br>¿Qué hace el dominio?<br>(Metas y Operaciones)"]
T["TASK (T)<br>¿Cómo se ejecuta el trabajo paso a paso?<br>(Secuencia de Acciones)"]
U["USER (U)<br>¿Quién procesa la info?<br>(Carga Cognitiva,<br>Roles, Sesgos)"]
R["REPRESENTATION (R)<br>¿Cómo se visualiza la<br>información externa?<br>(Cognición Distribuida)"]
%% Direccionamiento de las flechas del flujo
F --> T
T --> U
T --> REl Concepto Vital: complejidad intrínseca vs. dificultad extrínseca
- Complejidad Intrínseca: Es la naturaleza propia del acto médico (la comorbilidad del paciente, las interacciones farmacológicas, las guías clínicas). No se puede ni se debe eliminar.
- Dificultad extrínseca (Tareas parásitas): Es el estorbo introducido por mal software (menús anidados confusos, necesidad de memorizar un dato en la pestaña de paraclínicos para escribirlo en la pestaña de evolución, alertas irrelevantes que requieren confirmación obligatoria).
La conexión estratégica: TURF como contexto global de Dominio
Antes de programar cualquier módulo o invocar un agente de IA, se debe modelar la ontología del dominio en un archivo base (docs/domain_ontology.md):
U(Usuarios): Perfiles asistenciales, ventanas de atención y niveles de estrés.F(Funciones): Metas clínicas, entidades conceptuales, operaciones deterministas y restricciones normativas.- Matriz
U-Fu: Qué roles tienen autorización de ejecutar qué operaciones clínicas.
Cuando el desarrollador o el evaluador entregan esta ontología al agente de IA, el modelo comprende las reglas del hospital y deja de inventar interfaces arbitrarias o tareas parásitas.
Spec-Driven Development (SDD): El motor determinista con agentes de IA
Hoy los desarrolladores disponen de asistentes avanzados como Claude Code, Cursor, Windsurf o Copilot. Sin embargo, utilizarlos mediante prompts informales (Vibe Coding) en el sector salud es un acto de negligencia técnica: la deriva del context window y la naturaleza estocástica del LLM generan código inconsistente que no supera una auditoría de Software as a Medical Device (SaMD bajo IEC 62304 / ISO 13485).
La alternativa profesional es Spec-Driven Development (SDD):
“En SDD, el código fuente es únicamente una consecuencia determinista de una especificación matemática y semánticamente rigurosa. El agente de IA no adivina la arquitectura; implementa un contrato cerrado e inmutable.”
LOS 4 PILARES DEL CONTEXTO DETERMINISTA EN SDD
1. AGENTS.md (o CLAUDE.md) Guardrails operativos, comandos de prueba deterministas y checklist de salida. 2. docs/constitution.md Leyes inmutables del repo: tipado estricto, estándares (FHIR/OMOP etc) y tests >=90%. 3. specs/<id>/spec.md Requisitos funcionales en notación EARS y delimitación estricta de “Fuera de Alcance”. 4. specs/<id>/plan.md + tasks Arquitectura modular, contratos de datos y tareas atómicas (<30 min) con Test-First.
La Notación EARS (Easy Approach to Requirements Syntax)
Para erradicar la ambigüedad de las historias de usuario tradicionales, SDD adopta la sintaxis EARS, creada originalmente para la industria aeroespacial por Alistair Mavin:
- Requisito Dirigido por Eventos:
CUANDO <evento disparador>, EL SISTEMA <acción observable>
Ejemplo: “CUANDO el médico firme la orden de alta hospitalaria, EL SISTEMA generará el recurso FHIR DischargeSummary y notificará al servicio de farmacia.” - Requisito para Casos No Deseados (Manejo de Errores):
SI <condición de excepción>, ENTONCES EL SISTEMA <respuesta>
Ejemplo: “SI el servicio de terminologías no responde en 500 ms, ENTONCES EL SISTEMA utilizará la caché local de códigos CIE-10/SNOMED y registrará una advertencia de sincronización diferida.” - Requisito Basado en Estado:
MIENTRAS <estado clínico>, EL SISTEMA <comportamiento>
Ejemplo: “MIENTRAS el paciente se encuentre marcado en estado de Aislamiento por Contacto, EL SISTEMA mostrará un indicador visual permanente en la cabecera del registro.”
Mapeo Directo EARS ➔ Pruebas Automatizadas (TDD)
La gran ventaja para el desarrollador y el evaluador es que cada cláusula EARS se traduce 1:1 en una prueba unitaria:
CUANDO <evento>➔ Act (ejecución del comando o llamada a la API).EL SISTEMA <acción>➔ Assert (comprobación del resultado esperado).SI <error>, ENTONCES <respuesta>➔ Assert Error / Exception Handling.
El agente de IA escribe primero la prueba que falla (Test-First) y luego la implementación mínima necesaria para que la prueba pase. Si el código no cumple la especificación clínica, el compilador o el test runner lo rechaza automáticamente.
3. Guía de Aplicación: Cómo Gobernar el Desarrollo Paso a Paso
Tanto si usted está evaluando un software clínico para adquisición como si está liderando un equipo de desarrollo, este es el flujo de trabajo estándar que sugiero seguir:
flowchart TD
P1["1. Canvas de Negocio<br>(CRISP-DM)"] --> P2["2. Ontología del Dominio<br>(TURF / U-Fu)"]
P2 --> P3["3. Constitución & Guardrails<br>(Leyes del Repo)"]
P3 --> P4["4. Spec EARS & QA<br>(Caza de Ambigüedades)"]
P4 --> P5["5. Plan & Tareas Atómicas<br>(Desglose <30 min)"]
P5 --> P6["6. TDD con Agente IA<br>(Test-First ➔ Código)"]- Paso 1: Delimitar el retorno clínico (CRISP-DM): Defina en
docs/canvas.mdel problema exacto, las fuentes de datos y las métricas de éxito (KPIs) antes de considerar arquitecturas. Esto aplica si el proyecto involucra problemas con ciencia de datos. - Paso 2: Modelar la realidad asistencial (TURF): Capture en
docs/domain_ontology.mda los usuarios reales (U), sus restricciones cognitivas y la matriz de funciones del dominio (F). Limite lo mayor posible cualquier campo o clic que no pertenezca a la misión clínica del servicio. - Paso 3: Fijar las reglas del repositorio: Redacte
AGENTS.md. y docs/constitution.mdy establezca tipado estricto, uso obligatorio de vocabularios controlados (SNOMED-CT, LOINC, CIE-10) y cobertura de pruebas unitarias superior al 90% y las que considere necesarias. - Paso 4: Especificación formal (EARS) y rol de QA: Redacte
spec.mdsin mencionar nombres de archivos ni sintaxis interna. Someta el documento a una auditoría cruzada con el LLM activando un rol de QA independiente para detectar contradicciones y casos límite omitidos. - Paso 5: Modo plan y desglose atómico: Diseñe la arquitectura en
plan.mdy desglose el trabajo entasks.mden tareas pequeñas (< 30 minutos). Los agentes de IA alcanzan un 98% de precisión en tareas atómicas y fracasan estrepitosamente en tareas monolíticas. - Paso 6: Implementación Test-First y gestión del cambio: El agente escribe los tests antes del código. Regla de oro: Si surge un cambio en el requerimiento clínico, está prohibido parchar código en caliente; se actualiza primero la especificación (
spec.md) y luego se ajustan los tests y el código.
Conclusión: De la Ficción del Software a la Ingeniería de Salud Confiable
El sector salud no necesita más software desarrollado a la carrera, ni promesas vacías de algoritmos que nadie puede auditar.
Lo que la medicina exige de nosotros, tanto de quienes evaluamos tecnología como de quienes la programamos es la madurez de unir tres dimensiones complementarias:
- CRISP-DM nos da la disciplina de resolver problemas de negocio reales con datos verificables.
- TURF nos da la ciencia cognitiva para proteger la atención del clínico y erradicar tareas parásitas.
- Spec-Driven Development nos da el rigor de ingeniería para gobernar a los agentes de Inteligencia Artificial y producir código determinista, seguro y auditable.
Cuando estas tres capas operan juntas, la tecnología deja de ser una carga que agota al personal de salud y se convierte en lo que siempre debió ser: un instrumento silencioso y confiable para salvar vidas.
🛠️ Recursos y Toolkit de Código Abierto
Para facilitar la adopción inmediata de este flujo metodológico en sus instituciones y proyectos, he liberado una suite de plantillas-guía de código abierto diseñada para trabajar con agentes de IA (Claude Code, Cursor, Windsurf, Antigravity):
👉 Repositorio Oficial en GitHub: https://github.com/evertorres/crisp_turf_sdd
El kit incluye:
01_AGENTS.md: Guardrails y comandos deterministas para el agente.02_CRISP_DM_CANVAS.md: Canvas estructurado de viabilidad y datos.03_TURF_ONTOLOGY_UFU.md: Ontología del dominio y matriz de permisos U-Fu (el contexto global del sistema).04_CONSTITUTION.md: Plantilla de leyes inmutables del repositorio.05_SPEC_EARS.md: Formato formal con los 5 patrones EARS y límites de alcance.06_PLAN.md&07_TASK.md: Plantillas de arquitectura modular y desglose TDD atómico.08_PROMPTS_FASE.md: Playbook con los prompts exactos para guiar a cualquier LLM en cada fase sin alucinaciones.
