Buenas Prácticas de Simulación: cómo hacer que un modelo “in silico” sea confiable
En los últimos años, la simulación computacional ha dejado de ser “solo I+D” para convertirse en evidencia complementaria (y a veces decisiva) en el desarrollo de dispositivos médicos, fármacos y otras tecnologías sanitarias. Este avance trae una pregunta inevitable: ¿cómo demostramos que una simulación es suficientemente confiable para apoyar decisiones reguladoras y clínicas?
El informe Toward Good Simulation Practice (2024) propone una respuesta concreta: definir y aplicar Buenas Prácticas de Simulación (Good Simulation Practice, GSP), de forma análoga a lo que ya existe en biomedicina con GLP (Good Laboratory Practice) o GCP (Good Clinical Practice).
¿Qué es “Good Simulation Practice” y por qué importa?
En regulación, la evidencia tradicional es observada (ensayos, estudios, bench tests). En cambio, la evidencia de modelado y simulación es predicha, no observada. Por eso, además de “tener un modelo”, necesitamos probar su credibilidad en el contexto exacto donde se va a usar. La propia FDA reconoce el potencial del modelado y simulación (M&S) y la necesidad de mayor estandarización del flujo de trabajo: ahí es donde GSP se vuelve clave para consistencia y confianza.
Primer concepto clave: el Contexto de Uso (CoU)
Un modelo no es “bueno” o “malo” en abstracto. Un modelo es confiable para una pregunta concreta y en un contexto de uso (Context of Use, CoU) definido: qué decisión apoya, con qué alcance, y cómo se combina con otras evidencias (in vitro, in vivo, clínica). El documento también propone una manera clara de entender para qué se usa una metodología “in silico”: reducir, refinar o reemplazar experimentación (in vitro/ex vivo, animal o humana). Esto no es solo eficiencia: también es ética y sostenibilidad.
Segundo concepto clave: riesgo → nivel de exigencia
La simulación debe evaluarse con un enfoque basado en riesgo: no exige lo mismo un modelo de bajo impacto que otro que podría cambiar una decisión crítica. En el marco ASME VV-40, el riesgo del modelo depende de:
Influencia del modelo (cuánto pesa frente a otras evidencias), y
Consecuencia de la decisión (qué pasa si el modelo se equivoca).
Ese riesgo define cuánta verificación, validación, cuantificación de incertidumbre y análisis de aplicabilidad se requiere para considerarlo “suficientemente creíble”.
Tercer concepto clave: desarrollar modelos como software “de verdad”
Un modelo computacional es, en la práctica, un artefacto de software. Por eso, GSP insiste en prácticas de ingeniería: requisitos, diseño, control de versiones, documentación y pruebas sistemáticas. En proyectos de mayor riesgo, el propio enfoque recomendado es escalar hacia estándares y prácticas más estrictas, manteniendo siempre trazabilidad entre: CoU → requisitos → diseño → implementación → tests → versiones.
Cuarto concepto clave: credibilidad técnica (VVUQ + aplicabilidad)
Para modelos predominantemente mecanísticos, el documento apoya el enfoque clásico de VVUQ:
Verification (Verificación): ¿está bien implementado el modelo y resuelve bien las ecuaciones?
Validation (Validación): ¿las predicciones se parecen a datos experimentales comparables?
Uncertainty Quantification (UQ): ¿cómo afectan las incertidumbres de entrada al resultado?
Applicability (Aplicabilidad): ¿hasta dónde se puede extrapolar con seguridad lo validado?
Además, se propone pensar en niveles de credibilidad: desde predecir “dentro del rango poblacional” (L1), hasta acertar valores individuales (L3). No siempre hace falta L3: depende del CoU y del riesgo.
¿Y qué pasa con modelos basados en datos (IA/ML)?
Aquí el mensaje es muy directo: los modelos data-driven pueden sufrir concept drift (pierden precisión con el tiempo si cambian datos, práctica clínica o población). Por eso, su credibilidad no debería tratarse como “validación única y congelada”, sino como un plan de control de cambios y re-evaluación periódica (Predetermined Change Control Plan).
En otras palabras: si el modelo aprende del mundo, el mundo cambia; y tu control de calidad debe contemplarlo.
Roles y gobernanza: Sponsor e Investigator no son opcionales
GSP no es solo técnica. También es organización, responsabilidades y evidencia documental.
El Sponsor debe definir CoU, asignar recursos, asegurar calidad (riesgo “critical-to-quality”), mantener supervisión y, cuando externaliza simulaciones, auditar aspectos críticos como control de versiones, estándares y documentación.
El Investigator (modellers/analysts) debe asegurar recursos, mantener versionado de código/datos/resultados, reportar de forma regular, y aplicar medidas de seguridad y privacidad (p. ej., GDPR cuando aplique).
Checklist práctico: “¿estamos trabajando en GSP?”
Si estás desarrollando o evaluando una metodología in silico, estas preguntas ayudan a aterrizarlo:
¿La pregunta y el CoU están escritos y entendidos por todos?
¿Se estimó el riesgo del modelo (influencia × consecuencia)?
¿Existe un plan de desarrollo del modelo con requisitos trazables?
¿Hay versionado, documentación y pruebas automatizables por release?
¿La validación usa comparadores adecuados y bien caracterizados?
¿Se cuantificó incertidumbre y se delimitó aplicabilidad?
Si es IA/ML: ¿hay plan de control de cambios y re-test periódico?
¿Quedó todo reportado y “audit-able”?
Como equipo enfocado en tecnología médica, en Luperca Médica, GSP es una necesidad: si una simulación va a influir en decisiones de salud, debe ser reproducible, trazable y defendible.
El valor no está solo en “correr simulaciones”, sino en construir evidencia técnica y documental que aguante revisión interna, clínica y regulatoria, alineada al riesgo y al contexto real de uso.
