Platform Architecture
Elix is a set of domain services behind a single API gateway. The web app, the patient app and partner systems all talk to the same gateway, over the same API, with the same permission checks.
Services behind one gateway
Each clinical or operational domain is its own service with its own data model. The gateway receives every request at /api/v1/{service}/..., checks that the module is enabled for the facility, and forwards the request.
| Gateway prefix | Domain |
|---|---|
/api/v1/auth | Sign-in, tokens, users, roles and permissions |
/api/v1/patients | Patient register, demographics, privacy and the patient change feed |
/api/v1/appointments | Booking, schedules and queues |
/api/v1/encounters | Outpatient, inpatient, maternal and child health encounters, vitals and the FHIR Encounter interface |
/api/v1/investigations | Lab and imaging orders, results and FHIR diagnostic bundles |
/api/v1/billing | Bills, payments, payers, claims and pre-authorisation |
/api/v1/inventory | Stock, formulary and dispensing |
/api/v1/bims | Blood bank: donors, collections, screening and issue |
/api/v1/notifications | SMS, email and WhatsApp messaging |
/api/v1/admin | Facilities, configuration and the integration platform |
/api/v1/finance | Ledger, journals and financial reports |
/api/v1/tasks | Tasks and worklists |
The API reference documents the endpoints open to partners. Other routes exist for the Elix apps and may change without notice.
Tenants, organisations and facilities
Data is partitioned three ways:
- a tenant is the customer account, such as a hospital group;
- an organisation is a legal or business unit inside it;
- a facility is a site where care is given.
A signed-in user belongs to one tenant. Most clinical requests are answered for one organisation and facility, which the caller names in the x-org-id and x-facility-id headers or which default from the user's profile. A request can never read another tenant's data: a record outside the caller's tenant answers as not found.
Access control
Every route declares the permission it needs, such as patients.patients.list or investigations.lab.release. Roles bundle permissions, and users hold roles per facility. Modules are licensed per facility, so a route in a module the facility has not enabled is refused at the gateway.
Patient-identifiable reads carry a purpose of use (TREATMENT, PAYMENT, OPS or RESEARCH). The purpose is checked against the patient's privacy setting, a restricted record needs a recorded break-glass reason, and every read is written to the patient's access log.
Events and the outbox
When a service changes something other services care about, such as a lab result being released or a bill being settled, it records an event in an outbox table in its own database. A dispatcher then publishes it to the message bus, retrying until delivery succeeds, and other services, including messaging, react to it. A service restart does not drop an event that has been recorded.
FHIR
Elix speaks HL7 FHIR R4 at the edges:
- a read interface for encounters at
/api/v1/encounters/fhir/Encounter; - lab and imaging orders exported as FHIR
ServiceRequest,ObservationandDiagnosticReportresources; - a FHIR client that publishes those resources to a configured FHIR server, and a queue-backed sender that delivers patient records to health information exchanges and accepts their signed callbacks.
See FHIR exchange for the details.
Clients
- Elix web app for staff, in the browser.
- My Elix for patients, on web and mobile.
- Partner systems that call the API with their own credentials.
All three use the same API and are held to the same permissions.