Del episodio clínico a la reclamación liquidada — el ciclo de ingresos, diseñado en un solo motor.
Elegibilidad multi-pagador validada en admisión contra portales de pagadores nominados. Agrupador GRD parametrizado por mercado e integrado en la capa de datos — sin middleware entre la agrupación y la facturación. Liquidaciones con control de versiones e historial de auditoría completo. Reclamaciones emitidas en el formato requerido por cada pagador y según su calendario de envío. Gestión de denegaciones y ciclo de recurso en la misma superficie que la reclamación original. Auditoría médica pre-facturación integrada antes del envío. Sincronización automática con ERP: cada factura emitida genera el asiento en cuentas a cobrar e inicia el circuito contable.
Cobertura validada en admisión, no en facturación
Comprobación de elegibilidad en tiempo real contra portales de pagadores en el momento de la admisión — SITEDS para EsSalud Perú, SuSalud (regulador sanitario peruano), SEOGA para Sanitas España, CASS en Andorra, portales de aseguradoras privadas (Adeslas, DKV, Asisa, Sanitas, Mutua Madrileña). Episodios multi-cobertura — co-seguro estatal MUFACE/ISFAS, obras sociales latinoamericanas — resueltos en el motor de reglas antes de que se abra el registro clínico.
Liquidaciones con control de versiones
Cada ajuste a una liquidación emitida genera una nueva versión registrada. Los conceptos añadidos, modificados o eliminados quedan anotados con usuario, fecha y motivo. La pregunta del auditor — qué cambió, quién lo cambió y por qué — se responde como consulta sobre el historial de versiones, no como revisión manual de documentación.
Reclamaciones en el formato del pagador, según su calendario
Reclamaciones emitidas en el formato que cada pagador exige: TSI para la sanidad pública española, equivalente X12 837 para pagadores internacionales, formatos propietarios para el seguro privado. Cadencia de envío según el calendario de cada pagador — semanal, mensual, por evento. Liquidación conciliada por línea de reclamación: aceptada, denegada, parcial, controvertida.
Auditoría médica pre-facturación, no conciliación post-denegación
Auditoría médica integrada en el flujo de facturación antes del envío. Las inconsistencias entre la actividad clínica documentada en el HIS y los servicios presentados a facturación se detectan y resuelven antes de que la reclamación salga del sistema. La tasa de denegación se reduce en origen, no se gestiona a posteriori.
El ciclo de ingresos, nombrado en cada superficie.
Seis conceptos de primera clase en el motor de facturación — cada uno parametrizado, con control de versiones y auditable. El episodio es la unidad de trabajo; el pagador es el contexto de reglas; la reclamación es el sobre de auditoría.
Elegibilidad y reglas de cobertura multi-pagador
Validación de cobertura en admisión contra portales de pagadores nominados: SITEDS para EsSalud Perú, SuSalud, SEOGA para Sanitas España, CASS Andorra y la red de portales de aseguradoras privadas (Adeslas, DKV, Asisa, Sanitas, Mutua Madrileña). Las reglas de cada pagador — baremo de copago, estructura de franquicia, procedimientos excluidos, paquetes forfait, modelos de descuento — son filas en el diccionario del motor, no código personalizado por cliente. Episodios multi-cobertura (co-seguro estatal MUFACE/ISFAS, obras sociales latinoamericanas) resueltos en el motor de reglas: qué pagador adjudica primero, qué cubre la superposición secundaria, cuál es la obligación residual del paciente.
Agrupador GRD en la capa de datos
Mapeo de episodio a GRD parametrizado por mercado e integrado directamente en la capa de datos. El AP-DRG español, el G-DRG alemán y las variantes GRD latinoamericanas son cada uno una configuración del mismo motor — no implementaciones separadas codificadas en duro. Case-mix index reportado por hospital, por servicio, por trimestre. Tarifa por GRD y por pagador según contrato. Clasificación de estancias atípicas en el motor. Sin capa middleware entre el agrupador y la superficie de facturación; el GRD al que se resuelve el episodio es visible en cada paso posterior del ciclo.
Liquidaciones con control de versiones
Dos liquidaciones automáticas por episodio de paciente: una al financiador (valorización), otra al paciente. El motor de reglas aplica la lógica tarifaria completa — condiciones comerciales, plan de cobertura, copago, franquicia, forfait, descuentos y exclusiones — a ambas. Cada ajuste posterior a una liquidación emitida genera un nuevo registro versionado: los conceptos añadidos, modificados y eliminados quedan anotados con identidad de usuario, marca de tiempo y motivo. El historial de valorización es permanente y reconstruible para cualquier momento de la vida del episodio.
Generación de reclamaciones y liquidación de pagadores
Reclamaciones emitidas en el formato que exige cada pagador — TSI para la sanidad pública española, equivalente X12 837 para pagadores internacionales, EDI propietario para el seguro privado — según la cadencia de envío de cada pagador. Liquidación conciliada por línea de reclamación: aceptada, denegada, parcial, controvertida. Motivos de denegación categorizados y mostrados en el flujo de gestión de denegaciones; el ciclo de recurso genera una reclamación derivada enlazada a la original por referencia. Métricas de case-mix, tasa de denegación e ingresos por GRD reportadas por servicio y por pagador, disponibles para el director financiero sin intermediación del departamento de IT.
Facturación al paciente con lógica multi-cobertura
La parte del paciente calculada tras la adjudicación de cada pagador, conforme a los términos contractuales de cada cobertura en juego. Copago según contrato, franquicia acumulada por paciente y por pagador, máximo de bolsillo, tope vitalicio, superposiciones de pagador secundario para co-seguro de funcionarios — todo en el motor de reglas, aplicado de forma consistente en cada episodio y cada paciente. La factura del paciente lleva el desglose que el regulador y el paciente esperan. Emisión de factura electrónica con estado de validación en tiempo real.
Vista consolidada multi-entidad
Ingresos del grupo consolidados a lo largo de todas las entidades. Traslados inter-entidad de pacientes — admitido en un hospital, dado de alta en otro — conciliados en el libro mayor del grupo. Ingresos por GRD, case-mix index y tasa de denegación comparables en toda la red. La pregunta del CFO del grupo respondida como consulta. Sincronización automática con Axional ERP: cada factura emitida genera un asiento en cuentas a cobrar, inicia el circuito contable y se sigue hasta el cobro — cero doble entrada entre la facturación clínica y el back-office financiero.
Por qué el ciclo de ingresos tiene que estar en el motor.
La complejidad de los ingresos hospitalarios no está en el algoritmo del agrupador. El agrupador GRD es en gran medida una especificación publicada, disponible para cualquier proveedor dispuesto a implementarla. La complejidad está en las reglas a su alrededor: qué cuenta como un episodio frente a dos, cuándo una decisión clínica es administrativamente reembolsable, qué pagador adjudica primero en un escenario multi-cobertura, cómo se superpone el co-seguro de funcionarios al seguro privado, cuándo una denegación es recurrible y cuándo es final. Cada una es una regla que cambia por pagador, por mercado, por ciclo regulatorio. Implementarlas como middleware genera miles de líneas de código personalizado por cliente y un proceso de conciliación frágil que se rompe cuando cualquier regla cambia.
En Axional Health Suite, cada una de estas reglas es una fila en el diccionario — parametrizada, con control de versiones, auditable. El equipo que actualiza las reglas cuando una comunidad autónoma española modifica un umbral de cobertura, o cuando EsSalud Perú revisa el protocolo de validación de SITEDS, es el mismo que escribió el motor. El hospital no espera un parche de middleware ni retiene a un integrador especializado para mantener la conexión. Cuando la regla cambia, el ciclo de facturación la refleja en la siguiente admisión.
Hospital Angloamericano en Perú ejecuta Axional Health Suite junto a SAP para las finanzas corporativas y TrakCare para la gestión clínica. La arquitectura demuestra coexistencia, no sustitución: el módulo de ciclo de ingresos se conecta al sistema clínico aguas arriba mediante HL7, recibe los datos del episodio necesarios para agrupar y facturar, y sincroniza aguas abajo con el ERP para la contabilización en cuentas a cobrar. La superficie de integración es la interfaz estándar del motor — no un puente a medida construido para ese cliente.