La API SIIFA 1.0.9 fue publicada por el Ministerio de Salud el 14 de octubre de 2026 para los componentes técnicos de FEV-RIPS, seguimiento a facturas y seguimiento a pagos. La página oficial confirma la versión y su disponibilidad en pruebas y producción, pero no expone allí un detalle de cambios. Por eso, una IPS debe comparar especificaciones, ejecutar regresión integral y aprobar el despliegue con evidencia propia.
El micrositio oficial del SIIFA registró el 14 de octubre de 2026 la versión 1.0.9 de los artefactos API, Redoc, Swagger y colección Postman asociados a los módulos de FEV-RIPS, seguimiento a facturas y seguimiento a pagos, tanto para ambiente de pruebas como de producción. Es una novedad operativa relevante para pagadores, prestadores y proveedores tecnológicos que integran sus sistemas con el ciclo financiero del sector.
Hay una precisión indispensable: la publicación oficial visible confirma versión, fecha y archivos, pero no presenta en esa página un control de cambios detallado de la API SIIFA 1.0.9. Tampoco sería responsable deducir modificaciones funcionales comparando solo el número de versión. El enfoque correcto para una IPS es tratar el artefacto como una dependencia nueva que debe inventariarse, compararse y probarse antes de cualquier actualización productiva.
Esto es especialmente importante porque SIIFA no es una aplicación aislada. Conecta datos provenientes del MUV FEV-RIPS con la radicación, la auditoría, las devoluciones, las glosas, las respuestas y los pagos. Una variación de contrato técnico puede afectar consultas, automatizaciones, conciliaciones o tableros, incluso cuando la atención clínica continúa sin interrupción visible.
¿Qué es la API SIIFA 1.0.9 y qué evidencia existe?
Una API, o interfaz de programación de aplicaciones, define cómo dos sistemas intercambian solicitudes y respuestas de forma estructurada. En SIIFA, los manuales describen servicios REST, mensajes JSON sobre HTTPS, documentación OpenAPI/Redoc, autenticación mediante token JWT y ambientes separados de pruebas y producción.
La evidencia oficial permite afirmar lo siguiente:
- El portal SIIFA lista la versión 1.0.9, fechada el 14/10/2026, para API, Redoc, Swagger y Postman de los módulos 2, 3 y 4.
- Los artefactos aparecen disponibles en ambiente de pruebas y en producción con la misma versión y fecha.
- El Manual de Interoperabilidad del Módulo FEV-RIPS publicado en julio continúa listado como versión 1.0.2.
- Los manuales funcional y de interoperabilidad de seguimiento a facturas figuran como versión 1.0.2, fechada el 14 de agosto de 2026.
- El manual funcional de seguimiento a pagos aparece como versión 1.0.1 y el manual de interoperabilidad como 1.0.0.
¿Qué módulos pueden verse involucrados en la actualización?
La Resolución 1962 de 2025 desarrolló la estructura de SIIFA y estableció un modelo gradual. El portal institucional resume cuatro módulos: contratación, FEV-RIPS, seguimiento a facturas y seguimiento a pagos. La versión 1.0.9 publicada el 14 de octubre se asocia en la tabla a los tres últimos.
| Módulo | Objeto según la documentación oficial | Interacción que debe probar la IPS | Evidencia mínima esperada |
|---|---|---|---|
| FEV-RIPS, módulo 2 | Consultar facturas y RIPS, y registrar o consultar datos de radicación | Búsqueda por identificadores, paginación, radicación individual y masiva, consulta de alertas | Solicitud, respuesta, código HTTP, correlación y número de radicado |
| Seguimiento a facturas, módulo 3 | Registrar y consultar devoluciones, glosas, respuestas y resultados de auditoría | Estados, motivos, plazos, adjuntos o referencias, idempotencia y trazabilidad | Línea de tiempo completa por factura y actor |
| Seguimiento a pagos, módulo 4 | Registrar y consultar pagos, anticipos y amortizaciones | Aplicación parcial o total, referencias, saldos y conciliación | Correspondencia entre factura, pago y saldo |
| Contratación, módulo 1 | Registrar acuerdos de voluntades, novedades, otrosí y liquidación | Compatibilidad de CUCON y datos contractuales consumidos por módulos posteriores | Contrato vigente, aceptación y CUCON relacionado |
Aunque la actualización visible no se lista como versión 1.0.9 del módulo de contratación, este sigue siendo una dependencia del flujo. Una prueba integral debe comprobar que los identificadores y datos contractuales utilizados en facturación permanecen coherentes.
¿Por qué una IPS no debería actualizar solo por el número de versión?
El versionamiento informa que existe un artefacto nuevo; no reemplaza el análisis de impacto. Sin un changelog visible en la página, la IPS debe comparar la especificación anterior que tenga aprobada con la nueva publicación: rutas, verbos, parámetros, esquemas, obligatoriedad, enumeraciones, respuestas, seguridad y ejemplos.
La práctica prudente es declarar una línea base: versión productiva actualmente integrada, huella o copia controlada de la especificación, fecha de descarga, endpoints consumidos, credenciales por ambiente y casos de prueba aprobados. Desde allí, el equipo puede construir un diferencial reproducible.
¿Cómo se separan el MUV y SIIFA en las pruebas?
El Manual de Interoperabilidad del Módulo FEV-RIPS de SIIFA aclara que SIIFA no constituye el mecanismo de validación de la FEV ni del RIPS. La validación técnica, semántica y normativa corresponde al MUV; SIIFA consume información previamente validada y gestiona trazabilidad, radicación, seguimiento y consulta.
Esta frontera define dos familias de pruebas:
- Pruebas MUV: generación del XML y JSON, reglas de validación, rechazo, notificaciones, CUV y consistencia de la atención.
- Pruebas SIIFA: disponibilidad de la factura validada, consulta, radicación, estados, auditoría, glosas, respuestas, pagos y trazabilidad por identificadores.
Una factura puede superar el MUV y aun así presentar un problema de consulta o reporte en SIIFA. También puede fallar en el MUV antes de que el flujo SIIFA sea relevante. El tablero operativo debe distinguir ambas situaciones para asignar el incidente al equipo correcto.
¿Qué debe incluir la comparación técnica de la API SIIFA 1.0.9?
La comparación debe realizarse sobre los artefactos oficiales descargados, no sobre capturas o documentación secundaria. OpenAPI permite una revisión estructurada de contratos.
¿Qué revisar en endpoints y métodos?
- Rutas agregadas, eliminadas o renombradas.
- Cambios en verbos HTTP o parámetros de ruta y consulta.
- Modificaciones en paginación, filtros, ordenamiento y límites.
- Operaciones individuales frente a operaciones masivas.
- Respuestas síncronas, procesos diferidos y mecanismos de consulta posterior.
El manual del módulo 2 versión 1.0.2 documenta, entre otros, consultas de factura y alertas, radicación individual, radicación masiva y radicación masiva por identificador. Estos flujos son una base para diseñar casos, pero la especificación 1.0.9 descargada debe ser la referencia inmediata para el contrato técnico que se probará.
¿Qué revisar en los esquemas JSON?
- Campos nuevos, retirados o con obligatoriedad distinta.
- Cambios de tipo, longitud, formato, precisión o enumeración.
- Tratamiento de valores nulos, arreglos vacíos y caracteres especiales.
- Formato ISO 8601 de fechas y zonas horarias.
- Identificadores de factura, radicación, actor, contrato y transacción.
¿Qué revisar en seguridad y errores?
Los manuales describen autenticación con Bearer Token JWT y control por roles. La batería debe verificar obtención, expiración y renovación de token; autorización por perfil; rechazo de credenciales inválidas; protección de secretos; y ausencia de datos sensibles en registros técnicos.
También debe mapear códigos HTTP y cuerpos de error. Un sistema que trata todo 400, 401, 403, 404, 409 o 500 como “fallo de SIIFA” pierde la causa y puede repetir solicitudes que no son idempotentes. Cada respuesta necesita clasificación, mensaje operativo y regla de reintento.
¿Cuál es la matriz mínima de regresión para una IPS?
La matriz debe representar la operación real y puede organizarse en seis bloques.
- Autenticación y roles. Token válido, expirado y ausente; permisos de consulta y registro; segregación entre entidades y ambientes.
- Consulta de facturas. Búsqueda existente e inexistente; filtros; paginación; facturas con notas; relación con RIPS y alertas.
- Radicación. Registro individual, masivo y masivo por identificador; duplicados; reintentos; fecha y número único de radicación.
- Seguimiento de auditoría. Devolución, glosa, respuesta, aceptación o levantamiento; secuencia y consistencia temporal.
- Pagos. Pago total, parcial, anticipo y amortización; aplicación a facturas; conciliación de saldos.
- Resiliencia. Tiempo de espera, indisponibilidad, respuesta incompleta, límite de tasa, reanudación y recuperación sin duplicar operaciones.
Cada caso debe identificar dato inicial, operación, resultado esperado, evidencia, responsable y estado. Para volúmenes, conviene separar pruebas funcionales de rendimiento y acordar límites con la documentación oficial y la mesa de ayuda; no deben inferirse tasas que el Ministerio no haya publicado.
¿Cómo validar radicación, idempotencia y trazabilidad?
La radicación es especialmente sensible porque un reintento mal diseñado puede duplicar solicitudes o dejar el sistema local en un estado distinto del oficial. El manual del módulo FEV-RIPS explica que el pagador registra fecha de radicación y Número Único de Radicación, y que este número no constituye aceptación, aprobación de pago ni validación asistencial.
La IPS debe probar al menos:
- Qué ocurre si la conexión se corta después de enviar y antes de recibir respuesta.
- Cómo consultar el estado antes de repetir una operación.
- Qué clave identifica un intento único y cómo se conserva.
- Cómo se reconcilia un radicado existente que no llegó al sistema local.
- Cómo se procesan lotes parcialmente exitosos.
- Qué evidencia permite reconstruir actor, fecha, payload, respuesta y correlación.
¿Qué riesgos operativos debe incluir el plan de actualización?
| Riesgo | Señal temprana | Control preventivo | Respuesta operativa |
|---|---|---|---|
| Incompatibilidad de esquema | Aumento de 400 o errores de deserialización | Comparación OpenAPI y pruebas de contrato | Detener despliegue y corregir mapeo |
| Autorización insuficiente | Respuestas 401 o 403 por rol | Matriz de perfiles y rotación controlada | Validar credenciales y escalar sin compartir secretos |
| Duplicidad de radicación | Más de un registro para la misma intención | Idempotencia y consulta previa al reintento | Conciliar antes de reenviar |
| Pérdida de continuidad | Colas crecientes y tiempos de espera | Circuit breaker, cola persistente y monitoreo | Activar contingencia y procesar ordenadamente |
| Desalineación de estados | SIIFA y sistema local muestran ciclos distintos | Reconciliación periódica por identificadores | Abrir incidente con evidencia completa |
| Datos sensibles en logs | Payloads clínicos o credenciales visibles | Enmascaramiento y mínimo registro necesario | Contener, evaluar y tratar el incidente |
La guía de selección de software para IPS ayuda a ubicar SIIFA dentro de una arquitectura mayor que incluye HIS, facturación, RIPS e interoperabilidad. La evaluación debe probar las conexiones entre sistemas, no revisar módulos como vitrinas independientes.
¿Cómo desplegar la API SIIFA 1.0.9 con control de cambio?
Una actualización responsable puede organizarse en ocho pasos:
- Registrar la publicación oficial y descargar los artefactos desde el portal SIIFA.
- Verificar integridad, fecha y versión, y conservar una copia controlada de la línea base.
- Generar el diferencial OpenAPI y clasificar cambios por impacto.
- Ajustar cliente, modelos de datos, validaciones y manejo de errores donde sea necesario.
- Ejecutar pruebas automatizadas y manuales en el ambiente oficial de pruebas.
- Conciliar resultados con usuarios de facturación, auditoría y cartera.
- Desplegar de forma gradual, con monitoreo, criterio de reversión y responsables disponibles.
- Verificar en producción consultas, radicación y conciliación con un conjunto controlado antes de ampliar volumen.
Los criterios de salida deben exigir cero defectos críticos, autenticación estable, contratos aceptados, ausencia de duplicados, conciliación de los casos piloto y observabilidad suficiente. Una respuesta HTTP 200 no basta si el estado o el saldo quedaron incorrectos.
¿Qué debe exigir la gerencia al proveedor tecnológico?
La gerencia no necesita revisar cada esquema, pero sí exigir evidencia comprensible:
- Inventario de endpoints usados y módulos involucrados.
- Resultado de la comparación entre la versión aprobada y la API SIIFA 1.0.9.
- Matriz de regresión con casos, evidencias y defectos resueltos.
- Plan de despliegue, reversión, contingencia y soporte.
- Monitoreo de errores por módulo y tiempo de recuperación.
- Procedimiento para proteger credenciales y datos sensibles.
- Conciliación posterior entre SIIFA y el sistema institucional.
Una solución configurable para procesos clínicos y administrativos puede facilitar el cambio si mantiene interfaces estables, pruebas y gobierno de versiones. La personalización sin documentación, en cambio, amplía el riesgo cuando se modifica una dependencia externa.
Para una evaluación práctica, la IPS puede solicitar en una demo de Software Médico que se muestre cómo se enlazan atención, RIPS, factura, CUV, radicación y seguimiento. La demostración debe compararse con la especificación oficial y con requisitos propios; no constituye por sí sola certificación de compatibilidad.
¿Qué conclusión deja la API SIIFA 1.0.9 para las IPS?
La publicación del 14 de octubre de 2026 es una señal concreta para revisar integraciones. Confirma que existe un paquete 1.0.9 para FEV-RIPS, seguimiento a facturas y seguimiento a pagos en pruebas y producción. No confirma, en la página pública, cuáles cambios funcionales contiene; esa limitación debe permanecer visible en cualquier decisión.
El próximo paso es técnico y gobernable: fijar la versión actual, descargar la nueva especificación, producir un diferencial, ejecutar la matriz de regresión en pruebas y desplegar con reconciliación. La IPS debe conservar evidencia y consultar la mesa de ayuda del Ministerio cuando encuentre divergencias entre artefactos o manuales. Las decisiones regulatorias particulares requieren validación con la autoridad competente o asesoría profesional habilitada.
Preguntas frecuentes
Sí. El portal oficial lista la versión 1.0.9 del 14 de octubre de 2026 en ambientes de pruebas y producción para los artefactos asociados a los módulos 2, 3 y 4.
La tabla pública consultada muestra versión, fecha y enlaces de descarga, pero no expone allí un changelog detallado. Por eso, la IPS debe comparar los artefactos y evitar inferencias no verificadas.
No. El manual del módulo FEV-RIPS aclara que la validación técnica, semántica y normativa corresponde al MUV; SIIFA gestiona consulta, radicación y trazabilidad del ciclo financiero.
Como mínimo: autenticación, roles, consultas, radicación individual y masiva, duplicados, seguimiento de auditoría, pagos, errores, resiliencia y conciliación entre SIIFA y el sistema local.
No es aconsejable. La coincidencia de versión no demuestra compatibilidad con el cliente de la IPS. Se requiere regresión en pruebas, criterios de aceptación y verificación controlada en producción.
Software Médico puede apoyar la integración de datos clínicos, RIPS y facturación dentro de un flujo trazable, sujeto a la evaluación técnica de cada IPS y a los contratos oficiales vigentes. Para revisar escenarios de interoperabilidad, radicación y seguimiento con su equipo, solicite una demo o contacte a un asesor y lleve una matriz de casos reales, volúmenes y criterios de aceptación.
Fuentes oficiales consultadas
- Ministerio de Salud y Protección Social. Sistema Integral de Información Financiera y Asistencial (SIIFA). Consultado el 20 de octubre de 2026; lista los artefactos 1.0.9 con fecha 14 de octubre de 2026.
- Ministerio de Salud y Protección Social. Manual de interoperabilidad del módulo de FEV-RIPS del SIIFA. Versión 1.0.2, julio de 2026.
- Ministerio de Salud y Protección Social. Manual de interoperabilidad del módulo de seguimiento a facturas del SIIFA. Versión 1.0.2, publicado el 14 de agosto de 2026.
- Ministerio de Salud y Protección Social. Resolución 1962 de 2025: estructura y funcionamiento del SIIFA. Expedida el 23 de septiembre de 2025.
- Ministerio de Salud y Protección Social. Resolución 0948 de 2026: RIPS como soporte de la FEV en salud. Expedida el 14 de mayo de 2026.