Built to Hold Medical Records

1. Where We Stand

Diagnoses, prescriptions and billing histories pass through this platform every day. We treat protecting them as part of building the product rather than a compliance box to tick afterwards, and we assume any single control can fail — so there is always another behind it. The sections below describe those layers, from the disk up to the people with production access.

2. Encryption

• Everything stored — database, file uploads, backups — is encrypted at rest with AES-256.
• Everything moving between your browser and our servers rides TLS 1.2 or better. Plain HTTP is refused, not merely discouraged.
• Third-party credentials, such as the WhatsApp tokens a hospital connects, are encrypted before they are written down rather than sitting in plain configuration.
• Encryption keys are held apart from the data they protect and rotated on a schedule.

3. Who Can See What

• Every screen and API route checks the caller's role. A receptionist cannot open clinical notes simply by guessing a URL.
• Hospitals are isolated from one another at the data layer, so one tenant's query can never reach another tenant's rows.
• Passwords are stored as one-way hashes — we could not tell you your own password if you asked. Privileged accounts can add multi-factor authentication.
• Sessions are carried in an HTTP-only, same-site cookie that page scripts cannot read, and they expire rather than lingering forever.
• On our side, production access is limited to the few engineers who need it, granted for as long as they need it and no longer.

4. The Infrastructure

• We run on established cloud providers whose data centres carry independent physical-security certification.
• Firewalls, segmented networks and tight security groups mean the database is not reachable from the open internet at all.
• Backups run automatically, are encrypted, and are restore-tested — an untested backup is a guess, not a safety net.
• Dependencies and operating systems are patched promptly; anything rated critical jumps the queue.
• Inbound webhooks are signature-verified before we act on them, so a forged callback cannot make the platform do anything.

5. Standards We Work To

Our controls are built around recognised healthcare and data-protection practice. We sign Business Associate Agreements with covered entities that need one under HIPAA, and we operate under Indian data protection law for our domestic customers.

If your procurement team needs our security documentation before signing, ask — we would rather answer the questionnaire than have you assume.

6. Watching and Logging

• Systems are monitored around the clock for unusual behaviour, and alerts reach a human.
• Access to sensitive records is written to an audit trail, so a hospital can answer “who opened this file” after the fact.
• We run our own security reviews and bring in outside testers periodically, because a team rarely finds its own blind spots.

7. When Something Goes Wrong

We keep a written incident response plan and rehearse it. If an event touches your data, the sequence is: contain it, work out exactly what was reached, tell you without delay, and follow up with what we changed so it does not recur.

You will hear from us early enough to meet your own notification duties to patients and regulators. We would rather deliver an uncomfortable message quickly than a polished one late.

8. Found a Hole? Tell Us

Researchers who report problems privately make this platform safer, and we treat them accordingly — no legal threats, no stonewalling.

9. Talk to Us

Security questions, documentation requests and disclosure reports all land with the same team.