Trust centre
Only what we can show you.
This page lists the controls that exist in the running product today, each with the thing that makes it checkable rather than a promise. Your records are stored in the database and object store we operate; some optional features — AI drafting, transcription, video visits, email and WhatsApp delivery, GST e-invoicing — send data to the sub-processors listed further down, some of them outside India. What we have not built, or not yet proved, is at the bottom of the page under its own heading.
21 controls, each with its evidenceOne region · infrastructure we operateDPDP-aligned consent
What the database itself enforces
The two controls a hospital's IT committee asks about first are not written in application code, where a missing line would be enough to break them. They are constraints in the database, so they hold even for code that forgets.
One clinic can never read another clinic’s rowsEvery table that holds tenant data carries row-level security, and the account the application runs as is not allowed to switch it off. The tenant is bound to the transaction, not to a filter someone might forget to write.Enforced by the database, and tested on every push.
The audit trail cannot be edited or deletedPatient record opens, searches and exports are written once — who, when, from which address, under which permission, over which class of data. The log is hash-chained day by day, so removing or altering an entry breaks the chain.Append-only by database trigger; the chain is re-verified nightly.
Who gets in, and for how long
Access is short-lived by default and every widening of it — an emergency, a support visit — has an expiry and a reviewer attached before it is granted.
Passwords are hashed with Argon2id, and accounts lockPasswords are never stored or logged in a readable form. Five failed attempts lock the account, and every sign-in endpoint is rate-limited.Checked on every sign-in, before the password is even compared.
Two-factor authentication is available to every user, and an organisation can require itApp-based one-time codes with recovery codes. The secret is encrypted at rest; an administrator reset needs a written reason and is recorded. An organisation chooses whether a second factor is optional, required of its administrators, or required of everybody.The choice is enforced at sign-in, not suggested by the screen.
Sessions are short and refresh tokens rotateAn access token lasts fifteen minutes. Refresh tokens rotate on use, and re-use of an old one revokes the whole family. Every request re-checks that the session is still live, and shared devices idle out in five minutes.Revocation is checked server-side on the request, not trusted from the token.
Emergency access expires and must be reviewedA clinician can break the glass to reach a record in an emergency. That grant lasts at most four hours, ends by itself, and lands on a review queue; an unreviewed grant stays flagged.The expiry is a database constraint, not a reminder.
Our support access is time-boxed, and you can see itA MedAppz engineer cannot walk into your tenant. Access needs a written reason, defaults to thirty minutes with a two-hour ceiling, can be granted read-only, and appears in your own audit trail while it is happening.Expires on a scheduled sweep; visible to you, not just to us.
Two-person rules where one person should not decide aloneA purchase approval cannot be granted by the person who raised it, and role assignments are checked for the combinations that break segregation of duties.Self-approval is refused by a database constraint, not by a screen.
What happens to the data itself
Secrets, consent, exports, backups, transport, identity numbers and the mailbox — the places where clinic data is most often mishandled.
Credentials you give us are sealed and never shown backGateway keys, mailbox passwords and integration secrets are encrypted with a per-row key bound to your organisation. No screen and no endpoint will read one back to anybody, including us.There is no read-back path in the product; every decrypt is recorded.
Consent is checked per message, at the moment of sendingReminders, results and campaigns are gated on the consent notice the patient actually accepted, by version. Withdrawing consent cancels what is already queued. On a connected WhatsApp number, replying STOP or UNSUBSCRIBE withdraws it without anyone having to act on the message; by SMS the same reply works once the clinic has pointed its SMS gateway at the phone line’s opt-out URL, and until it does a texted STOP reaches nobody.Checked at the point of use and written to the audit trail each time. The SMS half is a setting the clinic makes, and CallDesk says so beside the line.
Exports are whitelisted, permission-checked and recordedOnly views we have listed in advance can leave the product. Each export needs the matching permission and is recorded with the row count and the classes of data it carried; spreadsheet formulas in patient data are neutralised on the way out.A view that is not on the list has no export at all.
Backups run nightly, are verified, and the restore is rehearsedThe database and the files are dumped every night and the dump is checked rather than assumed. The restore has been performed end to end, most recently on 3 September 2026.Verified nightly; the restore drill is a written procedure, not a plan.
TLS everywhere, and a content policy that blocks strangersCertificates renew automatically. The API answers with a deny-everything content security policy, and the application page blocks third-party scripts and connections outright.Set by the application, so it ships with the code rather than with a server setting.
Aadhaar and ABHA numbers are never stored in the clearOnly a hash and the last four digits are kept, which is enough to match a patient and not enough to reproduce the number.Refused by a database constraint if anything tries to store the full number.
Your mailbox is proxied, not copiedConnecting a clinic mailbox opens a live proxy to your own mail server: what arrives is read through the proxy and is never copied into our database. Mail you compose and send from MedAppz is the exception, and it is deliberate — the subject, the body and the recipient list are stored so that a send interrupted half way resumes from the rows rather than starting again, and so you can see afterwards exactly what went out.Received mail has no table to be stored in. Sent batches have one, and we keep it — see “What we do not claim yet”.
AI governance
AI in the product drafts; it does not decide, and it cannot be switched on quietly.
AI is governed like a controlled substanceEvery model call runs through a registered use case with a risk tier. Clinical and financial outputs must be grounded in your own records, and a named person accepts or discards the draft — the model never signs. Prompts are stored redacted and purged on a schedule. You can bring your own model key, or switch AI off entirely and keep the manual path.A call with no registered use case is refused; the retention sweep runs as a scheduled job.
Video visits happen on a server you can nameA video visit needs a video service configured for the deployment — a Jitsi server the clinic runs, not a public room. The join link is a signed token minted for one named person when they say they are going in, and it expires; it is not a room name pasted into a list. The patient gets their own link to the same room, as a guest — no moderator rights and no ability to record. With nothing configured, TeleCare refuses to schedule a visit at all rather than falling back. Turning recording on requires a service that can actually record; without one the switch refuses instead of setting a flag that means nothing.Rooms created before this — public rooms anybody with the link could enter — no longer produce a join link at all.
You decide what leaves for the model, and it applies to the wireOne setting per organisation: off, redacted or full, and redacted is the default. Redacted replaces the name of the patient a request is about with a role word, the date of birth with an age, and removes the hospital number, phone number and email address — from the outbound prompt and from the record excerpts, before the request leaves the process, not merely from the copy we keep. Anything else shaped like a phone number, an email address or a long identity number goes with it. A request whose record we cannot read is refused rather than sent with nothing substituted. Off means the AI buttons and consultation transcription refuse and say why, rather than sending a reduced version. A recording is the exception and we say so on the consent form: a voice cannot be reduced, so audio is either sent for transcription exactly as recorded, or not sent at all. What remains is the clinical text, which can still describe a person: this is a reduction in exposure, not anonymity, and we say so on the consent notice too.Applied between choosing the provider and calling it; each request records which of the three it received.
The discipline around the code
3 checks that fail a build rather than produce a warning nobody reads.
Migrations are forward-only and checksummedA schema change is applied once, in order, and its checksum is recorded. An edited migration fails the run rather than quietly diverging from what production has.The build applies them twice to prove a second run changes nothing.
A build that logs a patient field failsLog statements are scanned for the field names that carry patient data. The build fails on a match, so the class of leak that shows up in a support ticket months later cannot ship.Runs as a required check on every push.
Our own operator console cannot query patient dataThe console MedAppz staff use to run the platform is walled off from clinical data by the build: any code in it that names a clinical schema fails the check.Refused by the build, not by a policy someone remembers.
Sub-processors
Every outside service the product can send data to, what it receives, and where it processes it. A service reached only because you turned on the feature it powers is still on this list, and so is the company whose machine the database itself runs on. Some rows are your own systems — your mail server, your video server, a database you bring — and each says whose contract covers it. This table is generated from the register the product itself reads, so it cannot describe a set of vendors we no longer use. Nothing outside this list is sent your data, and we hold no signed processing agreement with any of the third parties on it yet.
Report a concernAnyone — clinician, patient, developer or a stranger — can report a safety problem or a security problem. No account needed. It goes to a mailbox a person reads, and we answer with what we found and what we changed.Email hello@medappz.com
Responsible disclosureCoordinated disclosure, ninety days. Please do not test against a live tenant — patient records sit behind these endpoints. We do not run a paid programme today, and we would rather say so than imply one.
What we do not claim yet
A trust page that answers every question is not credible to anyone who has run a procurement. These are the answers a buyer would otherwise have to extract from us.
- We are not ISO 27001 certified and we are not SOC 2 audited. Neither has been started.
- No external penetration test has been commissioned yet.
- Hosting is a single region on infrastructure we operate. There is no second region, no failover site and no published status page.
- Backups are nightly and verified, but are not yet held off-site or encrypted at rest.
- Mail you send from MedAppz is kept indefinitely — subject, body and recipient list. There is no retention sweep for it yet, and no button that deletes one; ask us and we will.
- Optional features send data outside India — AI drafting, transcription and message delivery. The table above is the whole list, and each row says whether it is on our contract or on a key you brought.
- We do not yet hold a signed data-processing agreement with any of the third parties in the table above. Getting them is work in progress, and until it is done the consent notice a patient reads says so too.
Two free self-audits, for the two questionnaires you will actually be handed
This page is what MedAppz does. These two are about what your own clinic or hospital has to do — each line saying whether the software enforces it for you, gives you the desk and the clock, or cannot help at all. Both score in the page; neither asks for anything to be useful.
Send this page to your IT committee, then send us their questions
A hospital's security questionnaire is longer than any page. Give us a number and we will answer it line by line — including the ones above where the honest answer is “not yet”.