1
Emprendimiento Sostenible.
Diego Alejandro Arias Vargas.
Asesor
Daniel Reyes
Corporación universitaria
Teinco
Programa
2026
2
1. Introducción
El presente documento define los requerimientos funcionales y técnicos para la reingeniería del
módulo de facturación de la IPS. El objetivo primordial es garantizar la integridad del ciclo de
recaudo, asegurando la concordancia entre la prestación del servicio asistencial y la generación
del soporte de cobro, bajo los lineamientos de la Facturación Electrónica en Salud y los
estándares de interoperabilidad vigentes.
2. Descripción General del Proceso
El sistema debe actuar como el núcleo integrador entre el área asistencial y el área financiera. Se
requiere una plataforma robusta que automatice la liquidación de servicios, minimizando el error
humano en la aplicación de manuales tarifarios (SOAT o ISS) y garantizando la correcta gestión
de las cuentas por cobrar ante la EPS.
3. Especificación de Requerimientos Funcionales (RF)
RF-01: Parametrización de Manuales Tarifarios y Acuerdos de Voluntades
El sistema debe permitir la carga y actualización de múltiples manuales tarifarios (ej. SOAT
vigente, ISS 2001 + % de incremento). Debe aplicar automáticamente los descuentos o tarifas
diferenciales pactadas en los contratos con la EPS para cada código CUP (Clasificación Única
de Procedimientos en Salud).
RF-02: Liquidación de Copagos y Cuotas Moderadoras
El módulo debe realizar la consulta automática de los derechos del afiliado mediante la
integración con la base de datos de la EPS. Basado en el salario base de cotización (SBC), el
sistema liquidará el valor exacto según los topes legales y el nivel de complejidad del servicio
prestado.
RF-03: Generación de RIPS (Resolución 2275 de 2023)
Es obligatorio que el software genere de forma nativa los archivos de Registros Individuales de
Prestación de Servicios de Salud (RIPS) en formato JSON, asegurando que cada factura
electrónica de venta (FEV) esté vinculada indisolublemente a su respectivo soporte de prestación
de servicios.
3
RF-04: Auditoría de Cuentas Médicas y Glosas
El sistema debe incluir un pre-validador de facturación que detecte inconsistencias (ej. falta de
autorización, códigos de diagnóstico CIE-10 no concordantes con el procedimiento) antes de la
emisión final, con el fin de reducir el índice de glosas por parte de la entidad pagadora.
4. Requerimientos No Funcionales (RNF)
RNF-01: Seguridad y Protección de Datos (Ley 1581 de 2012)
Dado que el sistema procesa datos sensibles y de salud, el desarrollador debe implementar
cifrado de punta a punta y niveles de acceso basados en roles (RBAC), garantizando que solo el
personal administrativo autorizado tenga acceso a la información financiera del paciente.
RNF-02: Disponibilidad y Escalabilidad
El sistema debe garantizar una disponibilidad del 99.9%, permitiendo la concurrencia de
múltiples usuarios en los puntos de admisión y egreso hospitalario sin degradación en los
tiempos de respuesta de la base de datos.
5. Reglas de Negocio
Validación de Autorizaciones: No se permitirá el cierre de factura si el número de
autorización de la EPS no ha sido validado o cargado previamente en el sistema.
Consistencia Diagnóstica: El sistema bloqueará la facturación de procedimientos que no
guarden relación clínica con el diagnóstico principal registrado en la historia clínica.
Modulo facturación.
1. Alcance del Módulo
El objetivo primordial de este componente es la transformación de la atención clínica en
Facturas Electrónicas de Venta (FEV) con validación previa. El módulo debe consolidar los
4
consumos generados en Consulta Externa, Urgencias, Hospitalización, Apoyo Diagnóstico y
Farmacia, asegurando la concordancia con los contratos suscritos con la EPS.
2. Requerimientos Funcionales Específicos (RF)
RF-01: Motor de Liquidación de Tarifarios
El sistema debe procesar automáticamente la liquidación de servicios basándose en el Manual
Tarifario SOAT (vigente) o ISS (2001 + porcentaje de incremento) según el contrato
seleccionado.
Lógica de liquidación: El desarrollador debe implementar algoritmos que apliquen
descuentos por "bilateralidad" en procedimientos quirúrgicos y recargos por horario
nocturno o festivos según la normativa nacional.
RF-02: Gestión de Copagos y Topes de Ley
El módulo debe calcular el valor a pagar por el usuario en el punto de atención.
Validación de Salario Base de Cotización (SBC): El sistema debe conectarse con el
módulo de admisiones para determinar si el paciente es Rango A, B o C.
Control de Topes: El software debe llevar un registro histórico anual por paciente para
alertar cuando el usuario haya alcanzado el tope máximo de copagos, bloqueando cobros
adicionales indebidos.
RF-03: Integración de Insumos y Medicamentos
El sistema de facturación debe realizar un "barrido" automático de la Bodega de Farmacia.
Todo insumo descargado en la historia clínica debe verse reflejado en la factura de manera
inmediata para evitar la pérdida de facturación por omisión de cargues manuales.
RF-04: Generación de Soporte XML y JSON (RIPS 2.0)
De acuerdo con la Resolución 2275 de 2023, el módulo no solo debe generar la factura en
formato XML para la DIAN, sino también el archivo de datos RIPS en formato JSON. Estos dos
archivos deben estar vinculados mediante el código CUFE (Código Único de Factura
Electrónica).
5
3. Requerimientos No Funcionales y Seguridad (RNF)
RNF-01: Trazabilidad y Auditoría (Log de Transacciones)
Cada cambio en un valor facturado debe quedar registrado con usuario, fecha, hora y el valor
anterior. Esto es vital para las auditorías de cuentas médicas que realiza la EPS.
RNF-02: Interoperabilidad HL7
Se recomienda que el módulo utilice el estándar HL7 para recibir mensajes de los equipos de
laboratorio y diagnóstico, permitiendo que el costo del examen se cargue a la cuenta del paciente
sin intervención humana.
4. Reglas de Negocio Críticas
Bloqueo por Autorización: No se permitirá la emisión de facturas de "Alta
Complejidad" si el campo "Número de Autorización" está vacío o no coincide con el
formato de la EPS.
Consistencia CIE-10: El sistema debe validar que el diagnóstico principal registrado por
el médico sea un código válido de la Clasificación Internacional de Enfermedades (CIE-
10) antes de procesar el RIPS.
Ejemplo de Tabla de Requerimientos para el Desarrollador
Código Requerimiento Descripción Técnica
Al cerrar la atención médica, el sistema debe
FAC-
Cierre de Folio generar un borrador de factura (Pre-factura) para
001
revisión de auditoría.
FAC- Manejo de Interfaz para marcar facturas devueltas por la
002 Glosas EPS, permitiendo la corrección y re-envío (Nota
6
Código Requerimiento Descripción Técnica
Crédito/Débito).
Capacidad de facturar a diferentes pagadores
FAC-
Multicontrato (EPS, ARL, SOAT, Particular) dentro de una misma
003
atención.