Trust Centre

Your health record is among the most sensitive information you own. This page explains, in plain language, how Niro protects it.

Who Controls Your Data

• You do. Niro is a patient-held record: nothing is visible to any doctor, dentist, allied health professional, pharmacy, laboratory or radiology centre unless you present your QR code or patient code, or book an appointment with them.
• Booking is an act of sharing. When you book an appointment, the hospital receives your name and telephone number so it can run the queue, and the practitioner you booked can open your record for that consultation — the same access you would give by handing over your code at the desk. Cancel the booking and that access goes with it.
• Channelling desk staff see the visit, not the history. Staff of an institution's channelling department can see your name, telephone number and queue position, the observations the clinic took before your consultation, and afterwards what it asked you to do next — plan, tests ordered, medicines prescribed, referrals raised — so the desk can send you to the right place. They cannot see your past consultations or the diagnosis made at this one.
• That is enforced by what we store, not by what we hide. Completing a consultation at a hospital writes a separate summary containing only those outputs, and the desk reads that summary rather than your record. Hiding fields in an app is a costume; this is a different document.
• Xtramile Consultancy Services (Pvt) Ltd (Sri Lanka) is the legal controller under the Personal Data Protection Act, No. 9 of 2022 (as amended in 2025).

Authentication

• Phone-verified identity: your account is anchored to your mobile number with SMS one-time codes at registration and at least every 30 days.
• Biometric unlock: day-to-day unlocking uses your device's fingerprint or face recognition. Biometric data is processed by your phone's operating system and never leaves your device — Niro cannot see or store it.
• Backup PIN: for devices without biometrics, a PIN (stored in protected form) unlocks the app; the periodic SMS re-verification still applies.
• Professional portals: doctors and dentists register with their SLMC number; allied health professionals register with their profession and council registration; pharmacies, laboratories, radiology centres and hospitals register their business identity. Every episode, prescription, order and visit note is stamped with its author.
• A professional cannot open their own record through a professional portal. Anyone who is both a clinician and a patient uses their patient account for their own care.

Verification of Professionals

• Doctors, dentists, allied health professionals and institutions can submit their registration certificate, professional identity card or institutional licence for verification.
• Submissions are reviewed by a named administrator against the relevant public register — the SLMC medical or dental register, the applicable professional council, or PHSRC and NMRA registration for institutions.
• The result is shown as a badge next to the professional's name. Where verification has not been completed, Niro says so plainly rather than staying silent, so you can judge for yourself.
• Verification documents are never shown to patients, and they are deleted when the account is deleted.

Encryption

• In transit: all traffic between your device and our servers is encrypted with TLS 1.2+.
• At rest: data is encrypted with AES-256 on our cloud infrastructure.
• Keys are managed by our cloud providers' hardened key-management services.

Data Residency and Processing

• Primary storage: Google Cloud / Firebase (Cloud Firestore for data, Cloud Storage for your uploaded documents and photographs, Google Identity Platform for authentication), in the Mumbai, India (asia-south1) region.
• Document reading: Google Cloud Vertex AI (Gemini) in the same Mumbai (asia-south1) region, under the same Google Cloud terms as the rest of our infrastructure; images are processed and returned, and are not used to train AI models.
• SMS: one-time codes are delivered through Text.lk, a Sri Lankan SMS gateway, which receives only your telephone number and the code itself.
• Video consultations: live audio and video are carried by Agora over encrypted connections, through relay servers outside Sri Lanka (typically Singapore). Consultations are not recorded, and no audio or video is stored. Access tokens are minted per consultation, for its two participants only, and channel identifiers carry no personal data.
• Cross-border transfers are made under section 26 of the PDPA (as amended): we maintain PDPA-equivalent obligations with our processors and obtain your explicit, informed consent at sign-up.

Referrals

• A referral carries what the referring practitioner wrote for it: who it is addressed to, the question, and their summary of your history. You can read it in full and print it.
• It is delivered only where the person referred to has a Niro account. Otherwise it is a letter you carry, and we do not pretend otherwise.
• A referral does not open your record to the person receiving it. They get the referral. Your record still needs you to present your code or book with them.
• Their reply is recorded in your record, not only in the two practitioners' inboxes. The answer to a question about your health belongs to you.

Observations Taken Before a Consultation

• Where a clinic nurse records observations before you are seen — blood pressure, pulse, oxygen saturation, temperature, blood sugar, weight, height — these are attached to that appointment, not to your record.
• The consultant is offered them and chooses whether to bring them into their consultation notes. Nothing is written into your record by desk staff.
• Recording observations does not require or grant access to your record.

Limits on Document Reading

Niro can read a photograph of a laboratory report, a prescription or a clinic note and offer you the details it finds, saving you the typing.

• It transcribes what is printed. It does not diagnose, advise or interpret.
• It never reads X-rays, scans, ECGs or any other image of the body. Imaging findings belong to a radiologist and are entered from the radiologist's report — never produced by software.
• Nothing is saved until you have read it and confirmed it, and the original photograph is always kept alongside the transcription so a clinician can check the source.
• The feature is optional. If you never use it, no image of yours is ever sent for reading.

Paying for Niro Premium

The heart of Niro is free — your record, your appointments, video consultations and home care. Niro Premium adds reading documents with AI, keeping photographs of your reports, and creating and managing your family's records. It costs LKR 1,999 a year by bank transfer, or LKR 199 a month by card.

If you pay by bank transfer, you upload a photograph of the receipt. We read it with the same AI that reads a lab report — only to check the amount, date and reference — and we match it against our own bank statement. The receipt is kept only until your payment is confirmed and is deleted within 90 days; it is never shown to a clinician or anyone else. Your card number is never seen by us: card payments go through PayHere.

When a paid period ends, Premium features stop — but nothing already in your record, including a document or a family member's record, is ever removed or hidden.

Institutions pay separately for the channelling plan — from LKR 2,000 a month by the size of the practice, first month free, by bank transfer with a receipt uploaded in their portal. Pharmacies, laboratories, radiology centres and allied health portals are free. An institution's plan is never charged to its patients, and a lapsed plan never touches a patient's record or their existing bookings.

Access Controls

• Per-record security rules: a record is readable only by its patient and by parties the patient has authorised.
• Access is a document, not a password. Knowing a patient code opens nothing. Reading a record requires a grant — a separate record naming the person, the patient, the scope and the expiry — and grants are written only by our servers. No client, and no user, can create one. Patient codes are short, and a system where the code is the credential is a system with a hundred thousand possible keys.
• Scoped to the job. Each grant carries the narrowest scope that does the work — the whole record for a doctor or dentist treating the patient, and less for everyone else: a pharmacy dispensing, a laboratory returning a result, a home carer on one visit, a delegate managing a relative's care, or the patient's own. The rules enforce the scope per collection, so a pharmacy's grant cannot read a consultation note even by asking directly.
• Expiry is built in. A consultation's grant lapses after a few days, a home care visit's two days after the visit, a returned result's after a few weeks. Only the patient's own grant and a named delegate's do not expire.
• Revocable by the patient. A patient can list every grant over their record and withdraw any of it. Enumerating access is what makes revoking it possible, so the rules deliberately allow a patient to list the grants that name them — and nobody else's.
• Emergency access is the exception, and it is loud. A registered clinician can open a record in an emergency — a patient who cannot consent, brought in unconscious — without waiting for consent, but never quietly. A reason is required and stored, the patient is notified the instant it happens, the access expires after two hours, and it is logged under the clinician's name like any other grant. The promise was never that no one could reach your record in a crisis; it is that no one can reach it invisibly.
• Our security rules are covered by an automated test suite that runs against the rules engine before release. It asserts both directions: that a clinician can open the chart of the patient in front of them, and that a stranger, an expired grant, a revoked grant and a wrong-scope grant are all refused. It has caught real faults — including rules that failed open-ended and rules that failed closed on legitimate users.

The Audit Log

Every grant of access to a record is logged with who, when, what scope and why, and the patient can read their own log.

We are precise about what this is. It records authorisation, not page views: once a party has been let in, they read the record straight from their device to the database, and our servers are not in that path. We would rather tell you exactly what we know than imply a level of surveillance we do not have.

The log is written by our servers only. Nobody — including the patient — can write or alter it.

Home Care Access

A carer sees a patient's record only while an accepted visit stands, and only the safety set: allergies, current medicines, current conditions, and the prescription behind anything a nurse has been asked to give.

They cannot read consultation notes, past visits or investigation results, and they cannot write anything into the medical record at all. What happened during a visit is recorded on the visit, not in the chart — a companion is not an author of clinical notes.

Every state change to a visit — accepted, declined, checked in, checked out, cancelled — goes through our servers rather than being written by either party's device. So does the price, which is taken from the carer's own published rates at the moment the visit is requested and fixed there. A carer cannot mark a visit complete they did not attend, and cannot raise the price on the way out.

A carer's eligibility to appear at all — verified, insured with an unexpired policy, agreement accepted, prices set, available — is recomputed by our servers on every change and swept nightly, because an insurance policy expiring is not an event anything writes.

Identity and Sign-In

Sign-in is by one-time code to a Sri Lankan mobile number, or for people abroad, to an email address, after which the device's own fingerprint or face unlocks the app.

Biometrics never leave the device. What we hold is a public key; the private key stays in the device's secure hardware, and we could not extract a fingerprint or face from what we store.

Identity verification — required before anyone can act on another person's record — is a document reviewed by a person. The trust level it produces is stored where its own subject cannot write it. A trust level the user can edit is not a trust level.

One-time code requests are rate-limited per number, per address and per source, with a daily ceiling, so that the code channel cannot be used to exhaust our sending credit or to harass a number.

Payments

Card details are entered inside PayHere's checkout and never reach Niro. We do not receive, process or store a card number.

A payment only becomes real when PayHere's own server tells ours it has, over a signed notification we verify. A client saying "I paid" is not accepted as evidence of payment by anything in the system.

Every payment is recorded with what it was for and what became of it. A payment that never resulted in the consultation or visit it was for is marked as owing a refund, so that the ledger stays honest even while refunds are issued by hand.

• Principle of least privilege for administrative access, with multi-factor authentication and audit logging.
• Our administration console handles verification submissions, service usage and support reports. It is restricted to named administrators and does not provide access to patient health records.
• No Niro staff access to identifiable health records except where strictly necessary for support you request, or as required by law.

Vendor Security

• Google Cloud: ISO 27001, SOC 2, and related certifications.
• Google Cloud (Vertex AI): ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 and related certifications; document reading runs in the same Mumbai region as the rest of Niro.
• Text.lk: a licensed Sri Lankan SMS gateway, used only for delivering verification codes.
• WhatsApp (Meta): the support channel offered under Settings, for help with your ACCOUNT — a lost PIN, the wrong record, a deletion request. Messages you send there travel through Meta's servers outside Sri Lanka and are governed by Meta's own terms, not ours, which is why the app asks you not to send medical details or photographs of your records to it. Nothing from your health record is ever sent to WhatsApp by Niro; what reaches it is only what you type. Using support is entirely optional — you can also write to us by email.
• Each acts as a processor bound by contract under PDPA section 21; none may use Niro data for its own purposes.

What We Never Do

• We never sell personal data.
• We never use health data for advertising or profiling.
• We never put health details in SMS or push notifications — a notification says a report is ready, never what it says.
• We never collect your biometric data.
• We never let software interpret a medical image.
• We never track your location. The "near me" option reads your position once, at the moment you tap it, to sort the list of nearby appointments.
• We never give a hospital's staff a standing view of the people who have attended it. Visit access is bounded by the appointment and expires.
• We never record video consultations.

Data Lifecycle

• Your record persists while your account is active — it is designed to be a lifelong health record.
• You can delete individual entries at any time, and you can export your whole record as a PDF before you go.
• Deleting your account starts a 30-day grace period. A health record takes years to build and seconds to lose, so signing in again within those 30 days restores it. After that, erasure is permanent and propagates to backups on a rolling basis within 30 days.
• Erasure removes your record, your uploaded documents and photographs, and your contact details from bookings. Entries a clinician made in someone else's record stay in that person's record — their history is theirs, not ours to remove.
• Data-subject requests (access, rectification, erasure) are answered within one month, free of charge, per the PDPA.

Incident Response

• Continuous monitoring for security events.
• Documented incident-response procedure with post-incident review.
• Personal data breaches are notified to the Data Protection Authority of Sri Lanka in the form and time required by its rules (PDPA section 23), and affected users are informed where required or where we consider there is a risk of harm.

Compliance

• Personal Data Protection Act, No. 9 of 2022, as amended by Act No. 22 of 2025 — including a Data Protection Management Programme (section 12), data protection impact assessments for our health-data processing (section 24), and processor contracts (section 21).
• Data Protection Officer appointed under section 20 — privacy@niro.lk.
• Internal compliance reviews conducted regularly.

Security Contact

• Report a vulnerability or security concern: security@niro.lk
• Privacy questions and data-subject requests: privacy@niro.lk