Skip to main content

Croydon, United Kingdom  ·  Asaba, Nigeria

Healthcare platform

Enluka EMR

A hospital records platform built around seven role portals — patient, doctor, nurse, laboratory, pharmacy, records and admin. The clinical and financial rules live in the database, so the workflow holds even when someone works around the screen.

Row-level security in Postgres Audit trail on every change Seven role-based portals Open Postgres, no vendor lock

The problem

Most hospital systems enforce the rules in the interface. Staff route around the interface.

A patient gets discharged with an unpaid laboratory bill. A sample is collected before payment clears. A prescription is dispensed against a drug the patient reacts to. In each case the software had a rule — it just lived in a screen that somebody skipped, or in a training document nobody reread.

Enluka EMR moves those rules down a layer. Payment gating, discharge clearance and record visibility are database constraints and triggers. The interface is a convenience over a database that defends itself, which means the rule holds for the API, the mobile view and the member of staff in a hurry.

Who it is for

Hospitals and clinics running paper or partly-digital records

Clinical directors who need the care pathway followed consistently

Records and finance teams reconciling treatment against payment

Laboratory and pharmacy teams working from a shared queue

Patients who want their own results, medications and appointments

Key capabilities

What it does

Registration and patient identity

Adult and paediatric registration with a unique patient identifier, caregiver linkage for minors, and check-in handled by the records desk.

Encounter workspace

Vitals, structured diagnoses typed as provisional, differential or definitive, SOAP notes, care team and results review in one clinical view.

Laboratory workflow

A status-tabbed queue from request to release: sample collection, structured result entry, electronic validation, then release back to the ordering clinician.

Prescribing and dispensing safety

Medication safety checks at the point of prescribing, stock warnings for the pharmacy queue, and a dispensing history against each patient.

Billing and payment control

A priced investigation catalogue, payment status visible across every portal, and collection or dispensing blocked until payment is confirmed.

Discharge clearance

The clinician recommends discharge; records approves it. Approval is refused while laboratory or pharmacy charges are outstanding, and issues an exit pass when it clears.

How it is put together

A self-defending database with a thin client on top

There is no bespoke middle tier to drift out of step. The browser talks to Postgres through a generated REST layer, and every access decision is a policy the database evaluates itself.

ClientReact single-page application
Role-grouped route guardsServer-state cachingSchema-validated formsPatient, clinician and admin portals
PlatformManaged backend services
Email and Google sign-inREST over every tableFile storage for attachmentsSession and JWT handling
DataPostgreSQL — the system of record
Row-level security policiesSECURITY DEFINER business functionsPricing and payment triggersAudit and history tables
InfrastructureStatic hosting and CI
Azure Static Web AppsCustom domain and SSLBuild and deploy on mergeVersioned SQL migrations

Integrations

It has to fit what you already run

The platform is built on open components, so integration is a matter of connecting to a documented interface rather than buying a connector.

Google Workspace sign-inEmail and password authenticationREST API over every tableSMTP transactional emailFile and image storageStructured data exportAzure custom domain and SSLSQL-level reporting access

Security & governance

Access control that does not depend on the user interface

Because the client is untrusted, correctness cannot depend on it. Every access rule is a database policy and every sensitive state change is a controlled function or trigger.

Row-level security policies decide what each role can read and write

Patients can only ever reach their own record — enforced in the database

Privileged operations run as fixed-scope SECURITY DEFINER functions

Clinical and financial state machines are enforced by triggers, not screens

Every change is written to an audit log with the acting user

Provider accounts require explicit approval before they gain access

Schema changes ship as reviewed, versioned migrations

Implementation

How a rollout runs

A department-first rollout. You see the system working on one real ward before it touches the rest of the hospital.

Clinical process mapping

We walk the current pathway with the people who work it — registration, triage, consultation, laboratory, pharmacy, discharge — and record where it actually breaks.

Configuration and catalogue setup

Departments, roles, staff accounts, the investigation catalogue and its pricing are configured against your tariff, not a generic default.

Data migration and rehearsal

Existing patient records are mapped, migrated and reconciled, then the cutover is rehearsed end to end before anyone commits to a date.

Pilot department

One department runs live with support on the floor. Findings are fixed before the scope widens.

Rollout, training and hypercare

Role-based training, super-users identified in each team, then a defined hypercare period followed by handover of the runbook.

See it against your own pathway

We will walk a real patient journey — registration through discharge — using your departments and your tariff, so you can judge the fit rather than a demo script.