For the CFO
Returns you can count. The funnel is a projection of an append-only ledger, and the CSV export reproduces it row for row — so the number you report and the number you can audit are the same number.
For hospitals
Bring your patients back.
Your brand, your clinicians, your appointment book — and a ledger that says which returns were yours.
Three people have to say yes
What this is, depending on where you sit.
So there are three answers, and none of them is the same answer.
For the medical director
A plan a clinician signs, and a queue built for many patients an hour rather than one. The engine drafts, the doctor decides, and nothing goes out unsigned.
For the IT lead
UAE-hosted, FHIR-shaped records, and tenant isolation enforced by row-level security at the database rather than by application code you have to trust.
What you get
Nothing you have to rip out.
We sit beside your HIS and your lab, read what they already produce, and write back into your own appointment book.
- Your existing patients, no acquisition spend
- Your brand in the patient's hand, not ours
- Lab PDFs are enough to start; a feed is better
- Booking into your own availability and branches
- A holdout arm, so lift is measured and not asserted
- Raw export, so finance can reproduce every number
The portal
Where your team works.
Four screens from the hospital side, running on synthetic demo data.
The attribution funnel
Every stage from delivered to visit confirmed, projected from the append-only ledger, with a CSV export that reproduces it row for row.
Synthetic demo data
The worklist
The patients who need something done today, and the confirm action that closes a booked visit.
Synthetic demo data
The weekly review
The queue a clinician moves through to adjust and sign the week's plans.
Synthetic demo data
Opportunities
Patients whose results suggest a follow-up that has not been booked yet.
Synthetic demo dataData residency and security
Written into the schema, not into a promise.
Every line here is a rule the code enforces and the test suite checks, because a hospital security review reads code, not marketing.
- Patient data stores and model inference stay in the UAE region.
- Clinical records are append-only or soft-delete only, kept for the long retention the region expects.
- Every tenant table has row-level security forced at the database; the application's role never bypasses it.
- Patient-data access is self or an explicit, revocable grant — family sharing is modelled, not improvised.
- Push notifications carry generic text and an opaque identifier. No marker, no value, no visit detail.
- Every assistant exchange writes an audit row, behind a guardrail layer that refuses diagnosis and medication changes.
Request a pilot
Start with one department
- Your existing patients, no acquisition spend
- Lab PDFs, or an HL7 or FHIR feed
- Every return counted, exportable
- Hosted in the UAE
No. We read what you already produce. A lab PDF is enough to start; an HL7 or FHIR feed is better. Booking uses your existing availability and branches.
Yours. The patient app is hospital-branded and multi-tenant, so your patients see your hospital, not us.
In the UAE. Patient stores and model inference stay in region, clinical records are append-only, and the database enforces tenant isolation with row-level security rather than trusting application code.
By the ledger. Every funnel action is written in the same transaction as the change that caused it, so the funnel and the raw export cannot disagree. You can also hold out a share of patients and compare.
From the founder
Why this exists
A private hospital in Dubai runs the test, prints the result, and then loses the patient. The abnormal marker goes unexplained, the follow-up goes unbooked, and the call centre reminder lands on someone who has already stopped listening. Meanwhile consumer health apps are busy monetising exactly the demand those labs created — explaining, in plain words, results the hospital produced and did not explain.
Hospital apps here are basic: booking and records at best. None of them read a patient fully enough to say what a result means, none of them close the loop back to a booked visit, and none of them can prove a return afterwards. That is not a technology gap so much as an unclaimed relationship.
So we built the boring half properly: read the lab report, explain it, let a clinician in your own team sign the plan, book into your own book, and write one auditable row for every step. The brand on the patient's phone is yours. The proof is a table your finance team can export and reproduce.
Prevention before cure.
Hosted in the UAEDoctor reviewedEvery return counted