How AEVONA helps
Why AEVONA hides the clinic's name until your booking is confirmed
It is the decision people question most, and the one that protects them most. Here is exactly what you see before confirmation, what you do not, and why the rule lives on our server rather than in the app.
The AEVONA care team6 min read
In short
- Before confirmation you see everything needed to judge a centre, and nothing that lets a booking happen outside the process.
- The name, full address, and phone number are released the moment AEVONA confirms your slot.
- The rule is enforced by the API, not by hiding fields in the interface.
- It exists to stop patients arriving at a chair that was never actually reserved.
Before you read this
AEVONA is a self-management diary and a booking service. It is not a medical device, it does not diagnose, and it never replaces your nephrologist or dialysis team. Always follow the advice of your treating clinician.
When people first see AEVONA's centre listings, the same question comes back: why can I see the audit score, the price, and the machine count, but not the name of the place?
It is a fair question, and the answer is not that we are protecting a directory. It is that an unconfirmed booking is the most dangerous thing we could hand a dialysis patient, and a phone number before confirmation is how unconfirmed bookings happen.
What you can see before you commit
Everything you need to choose between two centres is visible up front. The withheld fields are the ones that enable contact, not the ones that inform a decision.
| Shown before confirmation | Released after confirmation |
|---|---|
| City and area | The clinic's name |
| AEVONA audit score, out of 20 | The full address |
| Number of machines | The clinic's contact number |
| Price per session | An AEVONA booking reference |
| Whether the centre accepts travelling patients | The clinic's number added to your emergency contacts |
| How much advance notice the centre needs | — |
| Distance to the nearest emergency hospital | — |
Read that left-hand column again. It is the whole basis of a sensible decision — how well the centre scored on an audit we carried out ourselves, how much capacity it runs, what it costs, and how far help is if something goes wrong. The name adds nothing to that judgement. It only adds the ability to ring them directly.
What the rule prevents
The failure we are designing against is specific, and it is one that already happens to dialysis patients travelling in India today.
- A patient rings a centre, is told “yes, come on Tuesday” by whoever answered, travels several hundred kilometres, and finds no slot was ever recorded. Nobody lied. The booking simply did not exist anywhere.
- A patient arranges a session informally and arrives with none of the paperwork the unit needs — current serology in particular — and is turned away on the day.
- A centre agrees to a session it cannot actually staff, because the person on the phone did not know the shift was already full.
- A centre is left with a no-show slot it could have given to someone else.
Withholding contact details until AEVONA has confirmed the slot closes all four. When you get the name, a coordinator has already spoken to the centre, checked real capacity for your date and shift, and recorded the booking. The name is evidence that the work happened.
The nearest familiar comparison is a ride-hailing app that does not give you the driver's number until the ride is booked. It protects the passenger from an arrangement nobody is accountable for, and the driver from a fare that evaporates.
Why it lives on the server, not in the app
This is the part that matters technically. The withheld fields are not present-but-hidden in the app, greyed out or blurred behind a panel. They are not sent to your phone at all.
Our API defines two separate shapes for a centre: a public one that carries the area, score, capacity, price, and distance to emergency care, and a reveal shape that carries the name, address, and contact number. The reveal shape is only ever returned for a booking the server has already marked confirmed. A bug in the app, a modified build, or someone reading the network traffic gets the same answer as the interface does, because the interface was never the thing enforcing the rule.
We hold ourselves to it in the other direction too. Our own public website demonstrates the rule with two previews whose fields mirror those two API shapes exactly — if we ever quietly widened what is shown before confirmation, the page would have to change with it.
The trade-off we are accepting
This makes AEVONA slower than an instant booking service, and it puts a human coordinator in the middle of something software could pretend to do in a second. We think that is the right side of the trade.
A confirmation that a patient cannot rely on is worse than no confirmation, because they will travel on it. For someone who cannot miss a session, a yes has to mean a chair genuinely exists — and the only way to promise that honestly is to check, every time, before saying it.
Travel dialysis booking opens this Diwali, in November 2026. Nothing described here can be booked today — this site is where the launch will be announced.
Sources for the AEVONA claims above
PRS §6.1 FR-11.4 (the pre-booking visibility table)PRS §6.2 FR-12.6PRS §6.3PRS §6.4 FR-14.2–FR-14.4PRS §6.5 FR-15.1backend/api/openapi.yaml — CentrePublic, ClinicReveal
The clinical explanation in this article is general orientation prepared by the aevona care team. It cites no protocol and sets no targets, because the targets that apply to you are the ones your own dialysis unit has given you.