Patient identity, admissions and episode flow — the administrative shadow of the clinical record.
Demographics, admissions, transfers, episode tracking — and HL7 v2 / FHIR R4 ingestion from the clinical HIS. SNOMED CT and ICD-10 carried with the episode; IHE PIX, PDQ, XDS and ATNA in production. The administrative engine that keeps in lock-step with every clinical event the HIS records.
Demographics and identity
Patient master, identity reconciliation across clinical HIS, payer rosters and public-health registries. MPI integration where the regulator requires it. GDPR / LOPDGDD retention rules enforced at the data tier.
Admissions, transfers, discharges
Episode lifecycle from admission to discharge, transfers and re-admissions reconciled, length-of-stay metrics, ED-to-inpatient continuity. The administrative episode reflects the clinical episode in real-time.
HL7 v2 and FHIR R4 ingestion
ADT, ORM, DFT, MDM, SIU messages from the clinical HIS at runtime. FHIR R4 Patient, Encounter, Coverage, Account, Claim resources for the modern surface — bidirectional where the clinical system supports it.
IHE profiles in production
PIX (patient identifier cross-reference), PDQ (demographics query), XDS (document sharing) and ATNA (audit trail) — IHE profiles implemented for cross-enterprise integration with the national-health surface.
The administrative engine's view of the patient.
Identity, episode and demographic state — derived from the clinical record, reconciled across the payer roster, audited across the full chain.
Patient master with MPI reconciliation
Single patient master across the hospital network — multi-entity, multi-site. Master Patient Index reconciliation against the clinical HIS, against payer rosters, against regional public-health registries. Identity merges and splits handled with full audit history; the regulator's request to reconstruct a patient's identity history answered as a query.
Episode tracking from admission to discharge
Each clinical episode generates an administrative episode at the engine. Admission type (scheduled · emergency · day case · external referral), service department, attending physician, length of stay, transfer events, discharge disposition — all recorded as the episode unfolds. Re-admissions linked to the original episode for case-mix and outcome reporting.
HL7 v2 messages consumed at runtime
ADT^A01 / A02 / A03 / A04 / A08 (admission, transfer, discharge, registration, update) drive the administrative episode lifecycle. ORM (order entry) and DFT (financial transaction) drive the downstream billing module. MDM (document) drives the regulatory and patient-record handoff. SIU (scheduling) populates the appointment surface.
FHIR R4 for the modern integration surface
Patient, Encounter, Coverage, Account, Claim, ExplanationOfBenefit and Practitioner resources mapped to the Axional metadata repository. Bidirectional where the clinical HIS supports it — patient-demographic updates flow back, coverage changes flow forward, encounter status synchronises both ways.
SNOMED CT and ICD-10 as bridge codes
Clinical codes (SNOMED CT concepts, ICD-10 diagnoses, ICD-10-PCS procedures) ingested with each clinical message and bridged to administrative concepts at the metadata tier — billable encounter type, procedure for fee schedule, diagnosis for DRG grouper. Not in middleware. Not in batch reconciliation. At the engine.
IHE profiles for cross-enterprise flows
PIX and PDQ for patient identifier and demographics queries across the hospital and the national-health surface. XDS for document repositories and registries. ATNA for the audit-trail and node-authentication surface the regulator requires. Affinity-domain configuration per implementation.
Where the clinical HIS ends and the administrative engine begins.
The clinical HIS owns the patient story : diagnosis, treatment plan, medication administration, the clinical decision-support workflow at the point of care. That story is the medical record. It is owned by Epic, Cerner, IBM Sentry, or the public-hospital information system in the relevant market. Axional Healthcare does not write to that record.
What Axional Healthcare does is read every clinically-significant event out of that record — through HL7 v2 messages on the installed-base surface, through FHIR R4 resources on the modern surface — and reflect it into the administrative episode that sits parallel to it. The clinical episode is the source of truth for what happened to the patient. The administrative episode is the source of truth for the regulator, the payer, the auditor and the finance department. The two stay in lock-step because the engine consumes every clinical message in real time.
This shape — clinical HIS upstream, administrative engine downstream, connected by HL7 / FHIR / IHE — is the integration model the European and Latin American private hospital networks have converged on. Axional Healthcare is built for that shape.