Loading
We connect EHR, laboratory, pharmacy and billing so results, allergies and medications reach the clinician while the decision is still being made. It is built on HL7 and FHIR, and it runs on your cloud or in your data centre.
Four source systems • ONE SCREEN
Where it breaks
Every new system arrives with its own connector. Ten years later the estate holds dozens of point-to-point interfaces and one person who knows how results reach the ward.
Registration, labs, pharmacy and billing each hold part of the picture, and none of them agree on the patient identifier. Clinicians re-key data and chase results across screens.
One routing layer and a master patient index, so a patient has the same identity in every system.
The controls may well be in place, but the audit trail lives in three systems. When a regulator or payer asks, producing it becomes a multi-week manual exercise.
We log access centrally and export audit trails mapped to whichever regulation applies where you operate.
The HIS works, but it is a decade old and tightly coupled. Every change needs a weekend outage, so portals, analytics and new services stall behind the release calendar.
We wrap the core in APIs first, then move workloads in stages. The legacy system keeps running throughout.
How it works
Nothing gets rewritten at source. We normalise the messages, resolve patient identity, route the traffic and log every access on the way through.
Scroll the diagram sideways →
HL7 v2 for the interfaces that already exist, FHIR R4 and SMART on FHIR for everything new. When a vendor changes, you change a mapping and leave the architecture alone.
It runs on Azure, AWS, on premise, or split across both. Data residency rules usually make the decision, and we design to them.
Interface monitoring, retries and exception queues are in place from day one. We can run them under a support agreement if you would rather not.
Products
Health360, MetricMonitor and DwaniAI read the same normalised feeds. Patient identity and consent stay consistent whether you run one of them or all three.
Registration through discharge in one system: bed management, OPD and IPD workflows, pharmacy, diagnostics and billing.
Explore Health360 →Dashboards for clinical and operational teams. Bed occupancy, theatre utilisation, readmissions and revenue leakage, refreshed from live feeds.
Explore MetricMonitor →Appointment booking, reminders and follow-up over chat and voice, in the languages your patients speak. It hands over to staff when a question needs a person.
Explore DwaniAI →How we work
Every feed we build runs alongside the interface it replaces. Both produce output, your team compares them, and the old path stays live until you decide otherwise.
It is included in every engagement. Every cutover works this way, on the first feed and the fortieth.
We do not get to declare a feed correct. Your team does, by comparing it against the output you were already getting.
The interface we replaced stays configured until you retire it. Reverting at 2am on the fourth site takes a switch rather than a restore.
Recent work
Anonymised at the client's request
A private hospital group ran separate point-to-point interfaces from each site to a laboratory they all used. Results arrived in three different shapes, and a patient admitted at one site was a stranger at the other two.
We inventoried the estate, put a routing layer in front of the lab feed, and introduced a master patient index. Each site cut over in turn.
Talk to us about your estate →Questions
A single well documented feed can be live in six to eight weeks. A multi-site programme with identity resolution and several message types runs longer, usually three to six months. The pace usually depends on how quickly the source system vendor grants you interface access.
Get started
Tell us which systems you are trying to connect. A healthcare architect reviews it and comes back within two working days.
