Result explained
The marker your hospital measured, in plain words, with what it is and what happens next.
Hosted in the UAE
Prevention before cure.
Your hospital's results, explained. A plan your doctor reviewed. The next visit booked — and counted.
Explainedevery result, in plain words
Revieweda doctor signs the plan
Countedevery return, one row per patient
Built with hospital doctors in DubaiFHIR-shaped recordsDesigned for NABIDH-era data residency
How it works
A result becomes a plan becomes a visit.
Four screens the patient actually sees. These are captures of the app running on synthetic data.
See what needs attention
Seven body systems, computed from the results already in the record. No new test.
Follow the plan
A short plan of things to actually do, and a clinician's signature on it.
Book the next visit
The follow-up booked at your own hospital, at a branch and a time that exist.
The loop
Every plan starts with a result you already paid for.
One result, followed all the way to a booked visit and a row in the ledger.
01
The result arrives explained
Your hospital's lab report arrives already explained: what each marker is, what the result means for you, and what the next step is.
From your hospital. We read the lab report it already produced — either a PDF or an HL7 or FHIR feed — and explain it. We do not order tests and we do not run a lab.
It is quarantined rather than dropped. Every incoming result ends up delivered, quarantined or rejected, and a daily reconciliation checks that the three add back up to what came in.
02
The doctor reviews the week
A clinician works a weekly queue in the hospital portal, adjusts what the engine drafted, and signs it. Nothing reaches the patient unsigned.
Yes. The portal has a weekly review queue built for a clinician to move through many patients quickly, and a plan is not sent until it is signed.
The rules engine and the assistant draft; a clinician decides. The assistant runs behind a guardrail layer — no diagnosis, no medication changes, red flags escalated — and every exchange is written to an audit row.
03
The plan lives on the phone
The plan lives in the hospital's own app on the patient's phone, next to the reminders and the tracking that keep it honest.
A small number of things to do, tied to the results that triggered them, with a milestone that is never a daily chore. Medication reminders, activity and nutrition tracking sit alongside it.
Only through an explicit access grant. Sharing is a first-class part of the data model, not a workaround, and it can be revoked.
04
The visit is booked at your hospital
The follow-up is booked into your own appointment book, and the return is counted in the same ledger that the export is built from.
Your hospital's. Slots come from your own availability, at your own branches, and a confirmed visit lands on the portal worklist.
Every step writes a row to an append-only ledger in the same transaction as the change itself. The funnel in the portal is a projection of that ledger, and the CSV export reproduces it row for row.
In the box
What a pilot includes
Everything below is in the product today. Nothing here is a roadmap item.
01Results explained
02Digital twin
03Care plans with doctor sign-off
04Weekly review queue
05Booking at your branches
06Attribution funnel and export
07Family sharing
08Medication reminders
09Nutrition and activity tracking
10Patient messages
11Portal worklist
12UAE-hosted data
Reviewed by your own doctors
We do not employ your clinicians. You do.
There is no medical board here and no roster of faces. The doctor who signs a plan works at your hospital, in a queue built for their week.
The funnel
Every action in the loop writes one append-only row in the same transaction as the change itself. The funnel is a projection of it; the export reproduces it.
The worklist
The patients who need something today, and the confirm action that closes a booked visit against the ledger.
The weekly review
A queue a clinician moves through to adjust what the engine drafted and sign it. Unsigned plans do not go out.
What the hospital sees
The side your team works in.
Four screens from the hospital portal, 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 dataThe 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 data
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.
Prevention before cure.
Hosted in the UAEDoctor reviewedEvery return counted