De la admisión a la reclamación liquidada — el ciclo completo del paciente en un solo motor.
Cuatro circuitos paralelos — admisión, clínico, valoración, facturación — comparten un único maestro de datos y un único motor de flujo. Cada paso es trazable. Cada ajuste posterior al alta tiene control de versiones. El regulador, el auditor y el pagador leen la misma fuente.
Admisión en tres modalidades
Consulta externa, urgencias y hospitalización comparten el mismo maestro de pacientes, el mismo motor de cobertura y el mismo flujo de autorización. Cada modalidad tiene su propio ciclo de admisión; ninguna crea un registro de paciente independiente ni un libro mayor financiero separado.
Cobertura validada en admisión, no tras la facturación
Comprobación de cobertura en tiempo real contra los portales de pagadores — SITEDS, SuSalud, SEOGA, CASS y APIs de aseguradoras privadas — en el momento de la admisión. La autorización y la garantía quedan registradas antes de que se consuma el primer servicio, no reconstruidas en el momento de la reclamación.
Cuenta corriente diaria, cerrada al alta
Durante el ingreso hospitalario, la cuenta de consumo del paciente se actualiza automáticamente cada día. Al alta, la valoración convierte el consumo acumulado en una liquidación valorada. No existe conciliación por lotes entre el registro clínico y el motor de facturación.
Cada ajuste: versionado, auditable
Las correcciones posteriores al alta — ajuste de auditoría, ampliación de garantía, abono por error administrativo — crean una nueva versión de la liquidación que preserva el historial completo. Un auditor reconstruye la secuencia completa de eventos con una sola consulta sobre la misma fuente que utiliza el equipo de facturación.
Cuatro circuitos. Un motor. Sin sobrecarga de sincronización.
Cada circuito es un concepto de primera clase en el diccionario. El episodio es la unidad de trabajo; el maestro de pacientes es el contexto compartido; la reclamación es el sobre de auditoría.
Admisión y validación de cobertura
La recepción del paciente crea el registro del episodio: perfil clínico (alergias con gravedad y tipo de reacción, historial médico, medicación crónica, hábitos de vida), validación de cobertura contra el portal del pagador, autorización y registro de la garantía financiera o del depósito. Las admisiones se crean directamente en Axional Health Suite o se ingieren desde un HIS clínico aguas arriba mediante mensajería HL7 ADT. Tres modalidades — consulta externa (seis tipos de asistencia, tres plataformas), urgencias (introducción rápida de datos, cobro de copago en el momento), hospitalización (garantía financiera, carta de garantía de la aseguradora) — cada una con su flujo propio, todas alimentando el mismo maestro de pacientes.
Consumo clínico y cuenta corriente diaria
Durante el episodio, los servicios y productos se consumen contra la cuenta corriente del paciente. La cuenta se actualiza automáticamente cada día del ingreso hospitalario — sin conciliación manual, sin lote nocturno. El médico consulta el registro clínico; el motor de facturación consulta el consumo valorado. Ambos leen el mismo maestro de datos, por lo que un cambio de tarifa aplicado en el diccionario se refleja en el episodio abierto sin ningún trabajo de actualización en cascada.
Valoración, auditoría y liquidación
Al alta, la valoración final convierte el consumo acumulado en una liquidación valorada. La auditoría médica la revisa antes de su envío al pagador — auditor interno, auditor externo de la aseguradora, o ambos de forma concurrente en el mismo sistema. Cada ajuste sobre la liquidación crea un registro versionado: quién realizó el cambio, cuándo y por qué. La cadena de versiones es la pista de auditoría; no requiere un registro separado.
Facturación, cobro y sincronización con el ERP
El copago del paciente se calcula tras la adjudicación del pagador, según los términos contractuales de cada cobertura. Las facturas se emiten electrónicamente en el formato que exige cada régimen fiscal — TicketBAI y Verifactu para España, SII para la superficie de sanidad pública, CFDI para México, PLE y SUNAT para Perú, DIAN para Colombia. El lote al pagador se genera según el formato y la cadencia de envío de cada uno. Cada factura aterriza automáticamente en Axional ERP como un asiento de cuentas a cobrar, sin ningún paso intermedio de integración.
HL7 y FHIR en el límite de integración
Los mensajes ADT, ORM, DFT, MDM y SIU procedentes del HIS clínico se consumen en tiempo de ejecución. Los recursos FHIR R4 — Patient, Encounter, Coverage, Claim, ExplanationOfBenefit — dan soporte a la superficie de API moderna. La integración es bidireccional donde el sistema clínico lo permite. El HIS clínico es propietario del historial médico; Axional Health Suite es propietario del episodio administrativo y financiero. En producción: Dedalus HIS en MútuaTerrassa, TrakCare en Hospital Angloamericano junto a SAP ERP.
La superficie de auditoría que lee el regulador
Cada paso del ciclo registra el usuario, la fecha, el motivo y el estado del documento. Cualquier pregunta que plantee un auditor externo — qué paciente recibió este servicio, quién lo facturó, a qué tarifa, bajo qué plan del pagador, quién aprobó el ajuste — se responde como una consulta estructurada sobre una única fuente. La reconstrucción manual no es necesaria. La cadena de liquidaciones versionadas es el mismo artefacto que leen el equipo de facturación, el auditor médico y el regulador externo.
Por qué el ciclo tiene que estar en un solo motor.
Los grupos hospitalarios que operan con un HIS clínico, un ERP separado y un middleware de facturación arrastran una sobrecarga oculta de coordinación que aflora cada vez que cambia una tarifa, se actualiza una regla de cobertura o un pagador modifica su formato de envío. Cada cambio afecta a tres sistemas. Cada uno exige una ejecución de conciliación. Cada uno genera una ventana de inconsistencia durante la cual las decisiones de facturación se toman con datos que aún no reflejan la regla actualizada. En entornos en producción, esta sobrecarga se acumula: el equipo de facturación trabaja con los datos de ayer, el equipo financiero trabaja con los de la semana pasada y el auditor trabaja con los del trimestre anterior.
Axional Health Suite sitúa el ciclo en un solo motor. El cambio de tarifa se aplica una sola vez, en el diccionario. Todo lo que está aguas abajo — el episodio abierto, la reclamación pendiente, el honorario médico en cálculo — refleja el nuevo valor sin ningún lote ni parche de integración. El mismo motor que gestiona el libro mayor general del ERP gestiona la cuenta corriente diaria del paciente. El mismo diccionario que contiene el contrato con el pagador contiene la tarifa quirúrgica y el formulario de farmacia. Cuando el regulador modifica una regla de cobertura, el equipo que actualiza el diccionario es el mismo que escribió el motor. El hospital no necesita retener a un especialista en middleware para mantener tres sistemas alineados.