From clinical episode to settled payer claim — the revenue cycle, engineered into one engine.
Eligibility verification, multi-payer coverage rules, DRG-based billing, claims generation and payer settlement, patient invoicing with the multi-cover episode logic the Spanish and Latin American markets carry. The financial back-office of the hospital, audit-grade across the full chain.
Eligibility verification
Real-time coverage check against payer rosters at the moment of admission — private insurance, mutual societies, social security, state coverage. Multi-cover episodes (Spanish MUFACE / ISFAS state-employee co-insurance, Latin American obras sociales co-coverage) handled at the rules engine.
DRG-based billing
DRG grouper engineered into the data tier — episode-to-DRG mapping, case-mix index per hospital and per service, per-DRG payer rate by contract. Length-of-stay outliers handled at the engine. No middleware between grouping and billing.
Claims and payer settlement
Claims generated per payer's format and submission cadence. Settlement files reconciled at the line item — accepted, denied, partial, contested. Denial-management workflow at the engine; the appeal cycle visible in the same surface as the original claim.
Patient invoicing with multi-cover rules
The patient's portion of the bill calculated after payer adjudication, per the contract terms of each cover. Co-payment, deductible, out-of-pocket maximum, lifetime cap — all carried as engine-side rules, not custom code per implementation.
The revenue cycle, named at each surface.
Six surfaces of the cycle, each engineered as a first-class concept in the metadata repository. The episode is the unit of work; the payer is the rules context; the claim is the audit envelope.
Eligibility and coverage rules
Multi-payer eligibility at the moment of admission. Private insurance (Sanitas · Adeslas · DKV · Asisa), mutual societies (Mutua Madrileña, Mutua General de Catalunya), social security regimes (MUFACE for civil servants, ISFAS for armed forces, regional health authorities for the public-hospital surface), Latin American obras sociales — each payer carries its coverage rules at the engine.
DRG grouper engineered into the engine
Episode-to-DRG mapping at the metadata tier. Spanish AP-DRG, German G-DRG, Latin American DRG variants — the grouper logic is parameterised per market, not hard-coded. Case-mix index per hospital, per service, per quarter; per-DRG payer rate by contract; length-of-stay outliers triggered at the engine.
Claims generation per payer format
Claims emitted in the format each payer requires — TSI for the Spanish public-health surface, X12 837 for international payers, payer-proprietary formats for the private-insurance surface. The submission cadence honoured per payer's calendar (weekly · monthly · per-event). No batch reconciliation.
Settlement and denial management
Settlement files (835 in the US-standard equivalent, payer-specific elsewhere) reconciled at the claim-line item — accepted, denied, partial, contested. Denial reasons categorised against engine codes; the appeal cycle generates a derivative claim that stays linked to the original; case-mix and denial-rate metrics reported per service and per payer.
Patient invoicing with multi-cover logic
The patient's portion calculated after every payer's adjudication. Co-payment per contract, deductible-to-date carried per patient per payer, out-of-pocket maximum, lifetime cap, secondary-payer overlays for state-employee co-insurance — all at the rules engine. The patient's invoice carries the breakdown the regulator and the patient expect.
Multi-entity consolidation at the group view
Hospital-group revenue consolidated across all entities. Inter-entity transfers (a patient admitted at one hospital, discharged at another) reconciled across the group ledger; payer settlement aggregated to the group level; case-mix and revenue-per-DRG comparable across the network. The group CFO's question answered as a query, not as a reconciliation project.
Why the revenue cycle has to be in the engine.
The complexity of hospital revenue is not in the grouper logic. The DRG grouper is largely a published algorithm. The complexity is in the rules around it — what counts as one episode versus two, when a clinical decision is administratively reimbursable, which payer adjudicates first in a multi-cover scenario, how state-employee co-insurance overlays on top of private coverage, what triggers an outlier classification, when a denial is appealable and when it is final. Each of these is a rule that changes per payer, per market, per regulation cycle. Vendors who implement the cycle as middleware end up with thousands of lines of custom code per customer, and a fragile reconciliation process that breaks when any rule changes.
Axional Healthcare puts every one of these rules into the engine's metadata tier — parameterised, version-controlled, auditable. The same engine that runs the multi-entity ERP runs the multi-payer revenue cycle. When the regulator changes a coverage rule, the team that updates the metadata repository is the same team that wrote the engine. The hospital does not have to retain a specialist developer to maintain the integration.