Roadmap del Health Insurance Reserving Handbook¶
El avance se gobierna mediante entregables verificables y criterios de salida, no únicamente por cantidad de archivos.
1. Visión¶
El objetivo es consolidar una referencia profesional, abierta y reproducible sobre reservas en seguros de salud que combine:
- fundamentos y métodos actuariales;
- incertidumbre y modelación estadística;
- machine learning con benchmarks transparentes;
- operación de reclamaciones médicas;
- aplicaciones al sistema de salud colombiano;
- datos sintéticos, código, pruebas y visualizaciones;
- documentación, validación y gobierno de modelos.
2. Línea base actual¶
La versión pública más reciente es v0.5.0. Incorpora el flujo local de datos propios a triángulos
actuariales mediante Demo 5 y la comparación determinística Chain Ladder vs.
Bornhuetter-Ferguson en Demo 6.
| Componente | Estado actual |
|---|---|
| Capítulos | 40 capítulos en español |
| Partes | 7 partes temáticas |
| Demos | 6 demos reproducibles: tres bilingües y tres en español |
| Datos | Conjuntos sintéticos y diccionario canónico de reserving |
| Visualizaciones | Triángulos actuariales y comparaciones en SVG |
| Publicación | MkDocs Material y GitHub Pages |
| Calidad documental | Auditoría estructural, preflight y build estricto |
| CI | Validación y despliegue desde main |
Distribución de capítulos¶
| Parte | Tema | Cantidad |
|---|---|---|
| 1 | Fundamentos | 5 |
| 2 | Reservas clásicas | 6 |
| 3 | Reservas estocásticas | 3 |
| 4 | Modelos estadísticos | 3 |
| 5 | Machine Learning | 3 |
| 6 | Especificidades de salud | 8 |
| 7 | Colombia | 12 |
| Total | 40 |
3. Alcance cerrado hasta v0.5.0¶
- incorporación del demo pagado vs. incurrido;
- traducción y normalización de las Partes 1–7;
- corrección del renderizado matemático en GitHub;
- consolidación de front matter, H1 y navegación;
- actualización editorial de portada, roadmap, changelog y citación.
- marco de preparación de datos publicado en dos partes;
- matriz de requisitos y elegibilidad por metodología;
- diccionario canónico con nombres principales en español;
- Demo 4 de preparación y evaluación de datasets.
- Demo 5 local para construir triángulos con datos propios mediante Streamlit;
- Demo 6 local para seleccionar factores, proyectar el triángulo y estimar costo final y pasivo no pagado;
- prior directo o exposición por tasa esperada para Bornhuetter-Ferguson;
- comparación Chain Ladder vs. Bornhuetter-Ferguson por periodo de origen y total;
- sensibilidad, diagnósticos y exportación conjunta auditable de ambos métodos;
- sistema visual corporativo compartido con IgraSans local y componentes responsivos;
- suite automatizada para preparación, Chain Ladder, Bornhuetter-Ferguson, exportación e interfaces.
4. Hito publicado: v0.5.0¶
v0.5.0 amplía Demo 6 para comparar Chain Ladder y Bornhuetter-Ferguson bajo supuestos y
fuentes de información explícitos.
4.1 Exposición y expectativa previa¶
Entregables
- carga y validación de exposición por periodo de origen;
- selección documentada de una razón de pérdida o frecuencia-severidad esperada;
- reconciliación entre exposición, prima, expectativa previa y triángulo observado.
4.2 Bornhuetter-Ferguson¶
Entregables
- costo final y pasivo no pagado por periodo de origen;
- sensibilidad a la expectativa previa y a los patrones de desarrollo;
- comparación directa con Chain Ladder.
Sprint 1 del núcleo — implementado
- motor Python independiente de Streamlit;
- prior directo o reconciliado como exposición por tasa esperada;
- sensibilidad configurable del prior y diagnósticos por periodo;
- pruebas numéricas antes de integrar carga de archivos, interfaz y exportación.
Sprint 2 de integración — implementado y aceptado
- carga local de priors en CSV, TXT delimitado, XLSX o Parquet;
- mapeo de periodo de origen y prior directo o exposición por tasa;
- prior sintético reproducible, independiente del desarrollo observado;
- comparación visual Chain Ladder vs. BF por origen y total;
- sensibilidad configurable, diagnósticos y exportación conjunta auditable;
- pruebas del recorrido completo en Streamlit y de privacidad de la exportación.
4.3 Trabajo diferido¶
Benktander y Cape Cod quedan fuera del alcance de v0.5.0 y pasan al siguiente hito para no
mezclar la publicación validada de Bornhuetter-Ferguson con nuevos métodos aún no probados.
4.4 Comparación de métodos clásicos¶
El demo deberá explicar por qué los métodos divergen, mostrar sensibilidad por periodo de origen y mantener referencias cruzadas con los capítulos 6 y 11–14.
Criterio de salida
- resultados conciliados y reproducibles;
- priors y exposición trazables;
- comparación visual y tabular de costo final y pasivo no pagado;
- salidas y documentación en español, con expansión bilingüe planificada.
4.5 Cierre de v0.5.0¶
- auditoría documental limpia;
- build estricto exitoso;
- CI en verde;
- changelog y citación actualizados;
- release notes con alcance, limitaciones y comandos de reproducción;
- verificación del sitio publicado.
5. Próximo hito: v0.6.0¶
Sprint 1 · Base técnica documental¶
Este paquete deja preparada la especificación para:
- diagnósticos y backtesting fuera de muestra de Chain Ladder;
- contrato y trazabilidad del prior Bornhuetter-Ferguson;
- recurrencia, forma cerrada y sensibilidad de Benktander;
- exposición ajustada y estimación de tasa Cape Cod;
- comparación reconciliada de los cuatro métodos por origen y total.
El cierre documental no equivale al cierre funcional. El Sprint 2 completa Benktander; Cape Cod, backtesting ampliado y el comparador de cuatro métodos deben implementarse, probarse y conciliarse antes de declarar completa la versión v0.6.0.
Sprint 2 · Benktander funcional¶
- motor independiente con recurrencia y forma cerrada reconciliadas;
- selección explícita y trazable del número de iteraciones;
- equivalencia verificada entre una iteración y Bornhuetter-Ferguson;
- sensibilidad desde el prior inicial hasta las iteraciones configuradas;
- comparación visual no apilada de Chain Ladder, BF y Benktander;
- resultados por origen, totales, diagnósticos y configuración en el ZIP conjunto;
- pruebas numéricas, de entradas inválidas, privacidad y recorrido Streamlit.
El Sprint 3 incorporará Cape Cod sin modificar los resultados ya reconciliados. El backtesting común y el comparador final de cuatro métodos se mantienen como incrementos posteriores.
El foco propuesto es completar la comparación clásica y reforzar la validación:
- iteraciones Benktander configurables — completado en Sprint 2;
- estimación Cape Cod con exposición;
- diagnósticos y backtesting ampliados para Demo 6;
- comparación reconciliada de métodos clásicos;
- documentación y exportación reproducibles.
La incertidumbre mediante Mack y Bootstrap se mantiene como candidato para v0.7.0.
6. Camino hacia v1.0.0¶
La versión estable requerirá, como mínimo:
- revisión técnica transversal de los 40 capítulos;
- política bibliográfica y regulatoria uniforme;
- notación consistente entre capítulos y demos;
- código reproducible con pruebas automatizadas;
- datos sintéticos documentados mediante diccionarios y esquemas;
- validación de enlaces, matemáticas, navegación y accesibilidad;
- revisión independiente de afirmaciones colombianas sensibles a vigencia;
- política de versiones, deprecaciones y migraciones;
- evidencia de que una instalación limpia reproduce el sitio y los demos.
7. Definición de terminado¶
Un capítulo o demo puede considerarse validado cuando:
- tiene propósito, alcance y supuestos explícitos;
- utiliza notación coherente con el resto del handbook;
- sus cálculos se pueden reproducir;
- sus resultados se reconcilian;
- incluye limitaciones y riesgos de uso;
- tiene referencias cruzadas y enlaces válidos;
- supera las auditorías automatizadas;
- ha recibido revisión técnica o independiente proporcional a su materialidad.
La existencia de un archivo o su inclusión en la navegación solo indica disponibilidad, no validación completa.
8. Riesgos del proyecto¶
| Riesgo | Respuesta prevista |
|---|---|
| Afirmaciones regulatorias desactualizadas | Fecha de corte, fuentes oficiales y revisión periódica |
| Fórmulas que compilan en MkDocs pero fallan en GitHub | Auditoría matemática en CI |
| Demos que dejan de reproducirse | Semillas, pruebas y verificación de artefactos |
| Divergencia entre portada y contenido real | Inventario automatizado y consolidación por release |
| Métodos avanzados sin benchmark | Comparación obligatoria con referencias actuariales |
| Renombramientos que rompen URLs | Mantener rutas estables y planificar migraciones |
| Datos interpretados como experiencia real | Etiquetado explícito de datos sintéticos |
| Crecimiento sin revisión | Criterios de salida por hito |
9. Orden recomendado de ejecución¶
- publicación y verificación de
v0.5.0; - prueba de aceptación de Demo 5 con datos anonimizados;
- ampliación de diagnósticos y backtesting de Demo 6;
- incorporación de Cape Cod, con Benktander ya completado;
- comparación reproducible de métodos clásicos;
- cierre y publicación de
v0.6.0; - Demo 7 de incertidumbre para
v0.7.0.
No se asignan fechas hasta conocer capacidad de revisión y profundidad requerida. Cada hito debe cerrarse por evidencia.
