01
Discovery
We walk your current flows department by department and agree what goes live first. Most hospitals start where the pain is worst rather than with everything at once.
About PureBrix
The company behind the Brix
PureBrix builds hospital software around one patient record: SanoBrix for the whole hospital, and VitaBrix, VitroBrix, LumenBrix and CuraBrix for the chart, the laboratory, imaging and the pharmacy. One platform, built deeply, for hospitals that would rather run one system than reconcile four.
What we do
One platform, built deeply
Most hospital software companies sell a suite assembled from acquisitions. We build one system and scope it five ways, which is why the connections between its parts are the product rather than an integration project.
SanoBrix covers outpatients, wards, theatre, diagnostics, pharmacy, blood bank, sterile supply, dietary services, billing, claims and the shared services underneath them, and the other four products are parts of that same system a hospital can take on their own. The point is not the list — it is that a charge raised in theatre, a result authorised in the laboratory and a dose given on a ward all land in the same record and the same account, so nobody spends month end making four systems agree.
It runs in the hospital's own environment, serves every unit from one platform, and is configured by the hospital's own team rather than by us.
What we believe
Four positions, and what they cost us
These are not values on a wall. Each one is a decision visible in the product, and each one has a price we chose to pay.
01
One record, or it is not a system
A hospital running a clinical system, a billing system and a spreadsheet is running three systems and a reconciliation problem. Everything we build writes into the same patient record and the same account, because that is the only version of this that actually removes work.
02
Configured, not customised
A hospital that has to raise a ticket to open a ward is renting its own operations back from its vendor. Tariffs, forms, documents, numbering, roles and permissions are settings the hospital's own team controls. Customisation that needs us is the exception, not the model.
03
Say what it does, and what it does not
This website names what is built, what is newer, and what is absent — the AI that is in the product is kept separate from the agents still in pilot, there is no interface engine, and no certifications are claimed. A hospital evaluating a ten-year system deserves a straight answer more than it deserves a badge.
04
Built to be lived with
Hospital software is judged over a decade, not over one demo. The parts that make that possible — one record, rules held in one place, a permission model that does not depend on the interface behaving — are decisions taken early and paid for since.
How we talk about the product
What we will and will not put our name to
Healthcare software is sold on claims that are hard to check. These are the ones we have decided not to make, and you can hold us to them on every page of this site.
No customer counts until they are true
Number of hospitals, number of users, named references. A healthcare buyer verifies those first, and an inflated one costs more credibility than it buys.
No outcome percentages
No “reduces waiting times by 30%”. We describe what the system makes possible; what it achieves depends on your hospital, not on us.
No certification badges
The trust page states the mechanisms the platform gives you and says outright that no certification is claimed. Ask us a specific question and you get a specific answer.
What is newer is labelled
Where part of the product is less mature than the rest, this site says so rather than letting a grid of module names imply parity.
Working with hospitals
How an implementation goes
The part a hospital worries about most, and the part a website usually says least about. These are the stages. How long each takes depends on how many departments go live at once and what data is coming across — we will give you a real schedule for your scope, not a number from a brochure.
02
Configuration
Departments, services, tariffs, packages, documents, numbering, roles and permissions are set up for your hospital — by us alongside your team at first, and by your team on their own afterwards.
03
Data migration
Patient identities, service catalogues and outstanding balances come across from whatever you run today. This is usually the stage that decides the schedule.
04
Training
Role by role, on your own configured system rather than a demonstration one, so what people learn is what they will use.
05
Go-live
Supported on site or on call for the first days, when the questions come fastest and a slow answer costs the most.
06
After go-live
Support at the hours your hospital works, and a system your own team can keep changing without waiting on us.
Come and see the product
The fastest way to understand a hospital system is to watch one patient go through it.