La API SIIFA 1.0.8 es la versión de los artefactos de integración que el Ministerio de Salud publicó el 14 de septiembre de 2026 para los módulos de FEV-RIPS y seguimiento. Las IPS y sus proveedores deben comparar el contrato OpenAPI, probar consultas y respuestas, validar autenticación y trazabilidad, y desplegar de forma controlada. La publicación de la versión no demuestra por sí sola qué campos cambiaron.
El portal oficial del Sistema Integral de Información Financiera y Asistencial (SIIFA) publicó el 14 de septiembre de 2026 la versión 1.0.8 de los artefactos API, Redoc, Swagger y Postman para los módulos 2 y 3. La misma versión aparece para los ambientes de pruebas y producción.
Esta novedad es directamente relevante para IPS, entidades responsables de pago, proveedores de tecnologías y desarrolladores de sistemas médicos. Sin embargo, debe interpretarse con rigor: la ficha oficial confirma la versión, la fecha y los archivos disponibles, pero el portal no presenta junto a ellos una matriz pública de diferencias entre la versión 1.0.8 y su predecesora.
Por tanto, la adopción de la API SIIFA 1.0.8 debe tratarse como una gestión formal de cambio. No es responsable afirmar que se añadieron, eliminaron o modificaron campos específicos sin comparar los contratos publicados o contar con una nota oficial de versión.
¿Qué publicó exactamente el Ministerio el 14 de septiembre?
En la documentación del módulo de FEV-RIPS, el portal SIIFA identifica estos artefactos con versión 1.0.8 y fecha del 14 de septiembre de 2026:
- API FEV-RIPS SIIFA.
- Documentación Redoc.
- Especificación Swagger.
- Colección Postman.
La misma ficha muestra la versión 1.0.8 para la API, Redoc, Swagger y colección Postman del módulo de seguimiento a facturas. Además, el módulo de ingreso presenta la versión 1.0.2 de Seguridad API para pruebas y producción en esa misma fecha.
Esta combinación sugiere que el cambio debe analizarse de manera transversal. Una integración puede depender del contrato funcional del módulo, los esquemas de autenticación, las rutas consumidas y el comportamiento de respuestas o errores.
La palabra “sugiere” es importante: se trata de un análisis técnico derivado de la publicación simultánea. La ficha no declara por sí misma que todas las interfaces hayan sufrido cambios incompatibles.
¿Qué es la API SIIFA 1.0.8 y qué no es?
Una API, o interfaz de programación de aplicaciones, permite que dos sistemas intercambien información mediante reglas técnicas definidas. En SIIFA, estas reglas se documentan mediante estándares como REST, JSON, HTTPS y OpenAPI.
La API SIIFA 1.0.8 no debe confundirse con:
- El Mecanismo Único de Validación de FEV-RIPS.
- El software de facturación de la IPS.
- La factura electrónica validada por la DIAN.
- El archivo RIPS en sí mismo.
- El portal web de SIIFA.
El Manual de Interoperabilidad del Módulo de FEV-RIPS, versión 1.0.2 de julio de 2026, aclara que SIIFA no realiza la validación técnica, semántica y normativa de la FEV y los RIPS. Esa validación corresponde al Mecanismo Único de Validación. SIIFA consume información previamente validada y se orienta a la gestión, trazabilidad, seguimiento y consulta.
Esta separación funcional evita diseñar una integración sobre una premisa errónea. Obtener un CUV y consultar una factura en SIIFA son hitos relacionados, pero no equivalentes.
¿Cómo se ubica la API dentro del ciclo FEV-RIPS?
| Componente | Función principal | Datos o resultado | Control que corresponde a la IPS |
|---|---|---|---|
| Sistema clínico y administrativo | Registrar la atención y sus soportes | Usuarios, diagnósticos, procedimientos, medicamentos y valores | Calidad del dato desde la fuente |
| Facturación electrónica | Generar la FEV | XML validado previamente por la DIAN | Consistencia tributaria y sectorial |
| Mecanismo Único de Validación | Validar RIPS y su relación con la FEV | Resultado de validación y CUV | Gestión de errores y trazabilidad |
| SIIFA, módulo FEV-RIPS | Disponer y consultar información validada | Facturas, RIPS asociados, alertas y radicación | Integración, consulta y conciliación |
| SIIFA, seguimiento a facturas | Registrar y seguir auditoría de cuentas | Estados, glosas, respuestas y resultados | Monitoreo operativo y financiero |
| Sistema financiero de la IPS | Administrar cartera y conciliación | Estado de cuenta, recaudo y saldos | Correspondencia con eventos de SIIFA |
El flujo exige identificadores consistentes. Si el HIS, el facturador, el integrador y el módulo de cartera utilizan referencias distintas sin una tabla de correspondencia, la IPS puede perder la trazabilidad aunque cada plataforma funcione por separado.
La arquitectura también debe distinguir el proceso de validación única de RIPS y FEV de la consulta y el seguimiento realizados a través de SIIFA.
¿Qué funciones documentaba el manual anterior?
El Manual de Interoperabilidad del Módulo FEV-RIPS, versión 1.0.2, describe servicios REST para consulta de facturas, alertas, radicación y acceso a información RIPS. Entre las operaciones documentadas se encuentran:
GET /api/Factura.GET /api/Factura/{IdFactura}.GET /api/Factura/Alerta/{IdFactura}.POST /api/FacturaRadicado.POST /api/FacturaRadicado/Masivo.POST /api/FacturaRadicado/MasivoPorId.GET /api/FacturaRadicado/{IdFacturaRadicado}.GET /api/FacturaRadicado/ByIdFactura/{IdFactura}.GET /api/RipsTransaccion.GET /api/RipsUsuarios.GET /api/RipsUsuarios/{IdUsuario}.
El manual explica que los mensajes se intercambian en JSON sobre HTTPS, con codificación UTF-8, fechas basadas en ISO 8601, documentación OpenAPI y autenticación mediante Bearer Token JWT.
Esta lista sirve como línea base documental, no como confirmación de que todas las rutas permanezcan idénticas en la API SIIFA 1.0.8. La comparación debe realizarse contra los artefactos publicados el 14 de septiembre.
¿Qué debe comparar el equipo tecnológico?
La revisión debe ser estructural, semántica y operativa. Un simple cambio del número de versión en la configuración no demuestra compatibilidad.
¿Cómo comparar el contrato OpenAPI?
El equipo debería realizar una comparación automatizada entre la especificación utilizada actualmente y Swagger 1.0.8, revisando:
- Rutas añadidas, eliminadas o renombradas.
- Verbos HTTP permitidos.
- Parámetros de ruta, consulta y encabezado.
- Campos obligatorios y opcionales.
- Tipos de datos, longitudes, enumeraciones y formatos.
- Esquemas de solicitud y respuesta.
- Códigos de estado HTTP.
- Modelos de error.
- Reglas de paginación y filtros.
- Esquemas de autenticación y autorización.
Un cambio aparentemente menor, como convertir un campo opcional en obligatorio, puede interrumpir una integración. También puede haber cambios compatibles, como agregar una propiedad opcional que los consumidores tolerantes ignoren correctamente.
¿Qué debe revisarse en Postman y Redoc?
La colección Postman facilita pruebas reproducibles de rutas, variables, autenticación y ejemplos. Redoc permite examinar la documentación navegable del contrato.
Deben verificarse:
- Variables de ambiente.
- URL base de pruebas y producción.
- Encabezados requeridos.
- Obtención y renovación del token.
- Ejemplos de cuerpos JSON.
- Dependencias entre solicitudes.
- Datos de prueba autorizados.
- Respuestas esperadas y manejo de errores.
La colección oficial no sustituye las pruebas institucionales. Cada IPS debe comprobar cómo su propio integrador construye solicitudes, interpreta respuestas y actualiza estados internos.
¿Por qué la autenticación merece una prueba separada?
La autenticación es un componente transversal. El manual de julio documenta acceso mediante Bearer Token JWT, con operaciones restringidas según el perfil y la entidad.
Un token válido técnicamente no garantiza que el usuario tenga permiso sobre todas las operaciones. Las pruebas deben cubrir tanto autenticación como autorización:
- Emisión correcta del token.
- Vigencia y expiración.
- Renovación o reautenticación.
- Roles permitidos por operación.
- Respuesta frente a un token ausente, inválido o vencido.
- Protección del token en registros y herramientas de observabilidad.
- Separación de credenciales entre pruebas y producción.
- Revocación de accesos de personal o proveedores retirados.
Los tokens no deberían aparecer completos en archivos de log, capturas, correos o tableros de soporte. La trazabilidad puede conservar identificadores técnicos y resultados sin exponer secretos.
¿Qué pruebas necesita una IPS antes del despliegue?
Una actualización de integración debe superar pruebas técnicas y pruebas de negocio. La primera confirma que los mensajes circulan; la segunda verifica que el resultado corresponde al proceso institucional esperado.
¿Cuáles son las pruebas mínimas de contrato?
- Validar la especificación OpenAPI.
- Regenerar o revisar clientes automáticos, si la organización los utiliza.
- Ejecutar pruebas sobre cada endpoint consumido por la IPS.
- Probar solicitudes válidas e inválidas.
- Verificar campos nulos, vacíos, opcionales y obligatorios.
- Confirmar códigos HTTP y estructura de errores.
- Revisar paginación, filtros, fechas y zonas horarias.
- Comprobar compatibilidad con datos históricos.
¿Qué escenarios funcionales deberían probarse?
- Consulta de una factura disponible.
- Consulta por un identificador inexistente.
- Lectura de alertas asociadas.
- Consulta del radicado por factura.
- Consulta de información RIPS asociada.
- Procesamiento individual.
- Procesamiento masivo, cuando corresponda al rol.
- Respuesta ante duplicados.
- Error de esquema o catálogo.
- Token vencido.
- Intermitencia o tiempo de espera.
- Reintento sin duplicar una operación.
La última prueba es especialmente importante. Un sistema que repite automáticamente solicitudes después de una interrupción debe evitar registrar dos veces el mismo evento.
¿Cómo desplegar la API SIIFA 1.0.8 sin interrumpir la operación?
El despliegue debe ser progresivo y reversible. La IPS necesita conservar evidencia de qué versión utilizó, cuándo la activó y qué resultado obtuvo.
Un procedimiento razonable comprende:
- Inventario: identificar módulos, integradores, ambientes, credenciales y endpoints dependientes.
- Comparación: documentar diferencias entre el contrato actual y la versión 1.0.8.
- Clasificación: separar cambios compatibles, incompatibles, funcionales y de seguridad.
- Ajuste: actualizar modelos, validadores, mapeos y manejo de errores.
- Pruebas: ejecutar escenarios automatizados y validaciones de negocio en el ambiente permitido.
- Piloto: liberar la versión sobre un volumen controlado y observable.
- Despliegue: pasar a producción con responsables técnicos y funcionales disponibles.
- Conciliación: verificar que las operaciones enviadas coincidan con las registradas en SIIFA y en el sistema interno.
- Monitoreo: vigilar errores, latencia, reintentos, duplicados y diferencias de estado.
- Cierre: documentar resultados, incidentes, decisiones y versión definitivamente aprobada.
Un plan de reversión no debe depender de restaurar bases de datos indiscriminadamente. Puede consistir en conservar el cliente anterior, controlar la activación mediante configuración y detener temporalmente operaciones automáticas mientras se preservan las colas de trabajo.
¿Qué responsabilidades corresponden a la IPS y al proveedor?
La externalización del desarrollo no transfiere toda la responsabilidad institucional sobre el dato. La IPS necesita exigir evidencia verificable a su proveedor tecnológico.
| Responsable | Actividad principal | Evidencia esperada |
|---|---|---|
| Gerencia o patrocinador | Priorizar continuidad y recursos | Acta de aprobación y responsables |
| Tecnología | Comparar, implementar y monitorear | Informe de diferencias, pruebas y despliegue |
| Seguridad de la información | Revisar credenciales, roles y registros | Matriz de accesos y resultado de controles |
| Facturación | Validar estados y resultados del proceso | Casos funcionales aprobados |
| Auditoría o cuentas médicas | Confirmar trazabilidad y conciliación | Muestras conciliadas e incidencias |
| Proveedor tecnológico | Adaptar el sistema y demostrar compatibilidad | Versión liberada, pruebas y notas técnicas |
| Oficial de protección de datos | Revisar tratamiento y exposición de información | Evaluación conforme a políticas institucionales |
El proveedor debería informar qué artefacto oficial utilizó, qué rutas consume, cómo maneja errores y reintentos, y qué pruebas ejecutó. Una afirmación genérica de “compatibilidad con SIIFA” es insuficiente para gobernar el riesgo.
¿Cómo se relaciona SIIFA con la radicación?
La Resolución 948 establece que el pagador debe generar un número único de radicación y comunicarlo al emisor. También prevé que esa información sea reportada al Ministerio mediante el módulo FEV-RIPS de SIIFA.
El manual de interoperabilidad señala que el registro individual de radicación utiliza campos como el identificador de factura, el radicado y la fecha de radicación. También documenta operaciones masivas para optimizar el procesamiento.
Para la IPS, esto crea una oportunidad de conciliación automática:
- CUV obtenido.
- Factura puesta a disposición.
- Radicación reportada.
- Número único comunicado.
- Inicio de auditoría.
- Resultado y eventos posteriores.
El tablero financiero debería detectar facturas con CUV pero sin radicado, radicados que no aparecen en el sistema interno y diferencias entre fechas. Así se evita que una falla de integración permanezca oculta hasta el vencimiento de una cuenta.
¿Qué indicadores deben vigilarse después de actualizar?
La actualización no termina cuando la primera solicitud responde satisfactoriamente. Debe observarse su comportamiento bajo carga y a través del tiempo.
Los indicadores recomendados incluyen:
- Porcentaje de solicitudes exitosas por endpoint.
- Distribución de códigos HTTP.
- Latencia mediana y percentil alto.
- Tasa de expiración o rechazo de tokens.
- Solicitudes reintentadas.
- Eventos duplicados bloqueados.
- Facturas consultadas sin correspondencia interna.
- CUV sin radicación registrada.
- Diferencias entre estados internos y SIIFA.
- Tiempo de recuperación de incidentes.
- Versión del cliente desplegada por ambiente.
Las métricas deben excluir datos clínicos identificables cuando no sean indispensables. Los registros técnicos tienen que equilibrar observabilidad, confidencialidad y minimización de información.
¿Qué errores de implementación deberían evitarse?
¿Es suficiente cambiar la URL o el número de versión?
No. La versión publicada corresponde a artefactos de contrato que deben compararse. La URL puede mantenerse mientras cambian campos, respuestas o reglas de autorización.
¿Puede probarse directamente en producción?
No debería ser la primera opción. El portal diferencia ambientes de pruebas y producción. Las pruebas deben utilizar el entorno y los datos autorizados, seguidas de un despliegue controlado.
¿Conviene registrar todas las respuestas completas?
No necesariamente. Las respuestas pueden incluir información sensible. Deben definirse políticas de enmascaramiento, retención y acceso, conservando la evidencia necesaria sin replicar datos de salud de forma indiscriminada.
¿La actualización reemplaza los controles de RIPS?
No. La API facilita el intercambio con SIIFA, pero la generación y validación del RIPS mantienen sus propios controles. La IPS debe conservar la coherencia entre historia clínica, FEV, CUV, radicación y seguimiento.
¿Puede la IPS depender únicamente de pruebas manuales?
Las pruebas manuales ayudan a explorar escenarios, pero son insuficientes para una interfaz que puede cambiar. Una suite automatizada permite detectar regresiones ante futuras publicaciones.
¿Qué limitación tiene la evidencia disponible?
El portal oficial demuestra que la versión 1.0.8 fue publicada el 14 de septiembre de 2026 y que existen artefactos API, Swagger, Redoc y Postman para pruebas y producción. El manual público de interoperabilidad disponible en la misma página permanece identificado como versión 1.0.2 del 6 de julio de 2026.
No se encontró en la ficha consultada una nota de cambios que describa, campo por campo, las diferencias de la versión 1.0.8. Por esa razón, este análisis no adjudica a la versión nuevas rutas, campos o reglas concretas.
La determinación técnica debe realizarse comparando los archivos oficiales descargables y validando cualquier ambigüedad con la mesa de ayuda de SIIFA. Esa cautela evita transformar una inferencia en una afirmación normativa.
¿Cuál es la conclusión sobre la API SIIFA 1.0.8?
La API SIIFA 1.0.8 convierte la gestión de versiones en una responsabilidad operativa inmediata para las IPS y sus proveedores. La publicación reciente no exige asumir que todo cambió, pero tampoco permite seguir operando indefinidamente sin revisar el contrato actualizado.
El próximo paso es asignar un responsable técnico y otro funcional, descargar los artefactos oficiales, comparar la especificación, ejecutar pruebas de regresión y conciliar los resultados con facturación y cartera. La aprobación debe basarse en evidencia, no solo en una conexión exitosa.
Las IPS que institucionalicen este procedimiento estarán mejor preparadas para futuras versiones. La interoperabilidad no es un proyecto de una sola entrega: requiere control de cambios, seguridad, observabilidad y coordinación continua entre tecnología, facturación, auditoría y gerencia.
Preguntas frecuentes
Sí. El portal oficial registra la versión 1.0.8, con fecha del 14 de septiembre de 2026, tanto en pruebas como en producción para los artefactos indicados.
No. SIIFA consume información previamente validada y soporta su gestión, consulta y seguimiento. La validación de FEV-RIPS se realiza en el mecanismo correspondiente.
Debe inventariar las rutas que consume y comparar su contrato actual con el Swagger 1.0.8. Después debe ejecutar pruebas técnicas y funcionales en el ambiente autorizado.
La ficha oficial consultada no muestra una matriz detallada de diferencias junto a la versión. Los cambios concretos deben determinarse comparando los artefactos o mediante aclaración oficial.
No. La actualización de integración no sustituye los controles clínicos, administrativos y semánticos necesarios para generar registros consistentes.
Software Médico puede ayudar a conectar la operación clínica, la facturación y el seguimiento técnico que rodea la API SIIFA 1.0.8. Una IPS puede solicitar una demo o conversar con un asesor para revisar su flujo actual, sus puntos de integración y los controles necesarios antes de una actualización.
Fuentes oficiales consultadas
- Ministerio de Salud y Protección Social. Sistema Integral de Información Financiera y Asistencial — SIIFA. Portal consultado el 19 de septiembre de 2026; registra la API 1.0.8 y artefactos asociados con fecha del 14 de septiembre 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; versión fechada el 6 de julio de 2026.
- Ministerio de Salud y Protección Social. Resolución 1962 de 2025, incluida en el Boletín Jurídico No. 009 de septiembre de 2025. Norma sobre estructura, módulos, información y funcionamiento del SIIFA.
- Ministerio de Salud y Protección Social. Resolución 0948 de 2026. Expedida el 14 de mayo de 2026; regulación vigente del RIPS como soporte de la FEV.