Skip to content
MedOrbit

Built for India's health-data rules

Five rails, plainly stated — what is ready, what is certified, and what that difference means for you.

DPDP-ready

Consent is recorded in a ledger rather than assumed, and data-principal requests — access, correction, erasure — are handled inside the system with an audit trail. A data-subject access request runs as a tracked workflow here, not an email thread, and grievances route to a named contact.

What this means for you: Your compliance team gets a consent ledger and DSAR tooling built in, not a spreadsheet to build from scratch.

File a DPDP grievance →

ABDM-ready and NHCX-ready architecture

ABHA creation, consent-managed record sharing and FHIR R4 exchange are built and waiting on National Health Authority certification — architecture-ready, not a live claim today. NHCX claims follow the same pattern alongside PM-JAY, CGHS and ESIC scheme desks: the connectors ship with the platform and certify per deployment.

What this means for you: Ask any vendor for the certificate before believing a live-integration claim — ours is a documented, honest gap, not a hidden one.

GST e-invoicing and DLT-compliant messaging

Billing produces GST-compliant e-invoices inside the normal billing flow, not a separate finance export. Outbound SMS is built to India's DLT framework, with sender IDs and templates registered per tenant as each hospital goes live.

What this means for you: Your finance and compliance teams inherit invoices and message templates already shaped for Indian regulation, not ones retrofitted later.

Data residency in India

MedOrbit runs in AWS ap-south-1 (Mumbai) — patient records, documents and backups stay in that region for the life of the account. Access to patient data is logged per user, not just per role.

What this means for you: You can answer a data-residency question in due diligence with a region name, not a promise.

Tamper-evident clinical documents

Lab report PDFs are digitally signed, and the platform will not boot in production without the signing keystore in place. Every prescription carries a verifiable QR code, so either document can be checked outside the system that issued it.

What this means for you: A signed report or a scanned prescription can be verified independently, not just trusted because it came from your hospital's letterhead.

This page covers the regulatory and data-handling rails. For how MedOrbit keeps the AI itself safe — PHI redaction, human sign-off, audit trails, kill switches — see the safety architecture.

How we keep AI and data safe →

Compliance questions hospitals ask us

Is MedOrbit ABDM certified today?

No — ABDM-ready means the ABHA, consent and FHIR R4 workflows are built and waiting on National Health Authority certification. Ask any vendor who claims live ABDM integration for the certificate.

What happens if we receive a DSAR (data subject access request)?

It runs as a tracked workflow inside the system — access, correction and erasure requests are logged with an audit trail, not handled over email.

Where is our hospital's data physically stored?

In AWS ap-south-1 (Mumbai). Records, documents and backups stay in that region for the life of the account.