From admission to settled payer claim — the complete patient cycle on one engine.
Four parallel tracks — admission, clinical, valuation, billing — share one master data set and one workflow engine. Every step is traceable. Every post-discharge adjustment is version-controlled. The regulator, the auditor and the payer all read the same source.
Admission in three settings
Outpatient, emergency and inpatient share the same patient master, coverage engine and authorisation workflow. Each setting has its own admission cycle; none creates a separate patient record or a separate financial ledger.
Coverage validated at admission, not after billing
Real-time coverage check against payer portals — SITEDS, SuSalud, SEOGA, CASS and private insurer APIs — at the moment of admission. The authorisation and the guarantee are registered before the first service is consumed, not reconstructed at claim submission.
Daily current account, closed at discharge
During an inpatient stay, the patient's consumption account is updated automatically every day. At discharge, the valuation converts accumulated consumption into a priced liquidation. There is no batch reconciliation between the clinical record and the billing engine.
Every adjustment: versioned, auditable
Post-discharge corrections — audit adjustment, extended guarantee, credit note for administrative error — create a new version of the liquidation that preserves the full history. An auditor reconstructs the complete event sequence from a single query against the same source the billing team uses.
Four tracks. One engine. No synchronisation overhead.
Each track is a first-class concept in the metadata repository. The episode is the unit of work; the patient master is the shared context; the claim is the audit envelope.
Admission and coverage validation
Patient reception creates the episode record: clinical profile (allergies with severity and reaction type, medical history, chronic medication, lifestyle habits), coverage validation against the payer portal, authorisation, and registration of a financial guarantee or deposit. Admissions are created directly in Axional Health Suite or ingested from an upstream clinical HIS via HL7 ADT messaging. Three settings — outpatient (six care types, three platforms), emergency (fast-track data entry, co-payment at the door), inpatient (financial guarantee, insurer letter of guarantee) — each with its own workflow, all feeding the same patient master.
Clinical consumption and the daily account
During the episode, services and products are consumed against the patient's current account. The account is updated automatically every day of the inpatient stay — no manual reconciliation, no nightly batch. The physician sees the clinical record; the billing engine sees the priced consumption. Both read the same master data, so a tariff change applied to the metadata tier is reflected across the open episode without a downstream update job.
Valuation, audit and the liquidation
At discharge, the final valuation converts accumulated consumption into a priced liquidation. The medical audit reviews it before submission to the payer — internal auditor, external insurer auditor, or both concurrently in the same system. Each adjustment to the liquidation creates a versioned record: who made the change, when, and why. The version chain is the audit trail; it does not require a separate log.
Billing, collection and ERP synchronisation
Patient co-payment is calculated after payer adjudication, per the contract terms of each cover. Invoices are emitted electronically in the format each fiscal regime requires — TicketBAI and Verifactu for Spain, SII for the public-health surface, CFDI for Mexico, PLE and SUNAT for Peru, DIAN for Colombia. The payer batch is generated per payer's format and submission cadence. Every invoice lands automatically in Axional ERP as an accounts-receivable entry, with no intermediate integration step.
HL7 and FHIR at the integration boundary
ADT, ORM, DFT, MDM and SIU messages from the clinical HIS are consumed at runtime. FHIR R4 resources — Patient, Encounter, Coverage, Claim, ExplanationOfBenefit — support the modern API surface. The integration is bidirectional where the clinical system supports it. The clinical HIS owns the medical record; Axional Health Suite owns the administrative and financial episode. In production: Dedalus HIS at MútuaTerrassa, TrakCare at Hospital Angloamericano alongside SAP ERP.
The audit surface the regulator reads
Every step in the cycle records the user, date, reason and document state. Any question an external auditor raises — which patient received this service, who billed it, at what tariff, under which payer plan, who approved the adjustment — is answered as a structured query against a single source. Manual reconstruction is not required. The version-controlled liquidation chain is the same artefact the billing team, the medical auditor and the external regulator read.
Why the cycle has to be one engine.
Hospital groups that run a clinical HIS, a separate ERP and a billing middleware carry a hidden coordination overhead that surfaces every time a tariff changes, a coverage rule updates, or a payer modifies their submission format. Each change touches three systems. Each requires a reconciliation run. Each produces a window of inconsistency during which billing decisions are made against data that does not yet reflect the updated rule. In production environments, this overhead compounds: the billing team works from yesterday's data, the finance team works from last week's, and the auditor works from last quarter's.
Axional Health Suite puts the cycle on one engine. The tariff change is applied once, in the metadata tier. Everything downstream — the open episode, the pending claim, the physician fee in calculation — reflects the new value without a batch job or an integration patch. The same engine that carries the ERP general ledger carries the patient's daily current account. The same metadata repository that holds the payer contract holds the surgical tariff and the pharmacy formulary. When the regulator changes a coverage rule, the team that updates the metadata is the same team that wrote the engine. The hospital does not retain a middleware specialist to keep three systems in agreement.