Security and trust
Designed so that nobody sees more than they need
Here is what is built into the platform, and where we are honest about what is still ahead.
Principles
Permission-based access
Every request for health information is tied to a specific, approved purpose rather than open-ended access.
Role-based views
A pharmacy, a lab, and a doctor are shown different slices of a record, scoped to what their role needs.
Audit trail
Access is designed to be logged, so patients can see who requested information and when.
Encrypted transmission and storage design
Health data is designed to be encrypted in transit and at rest within ArogyaCard infrastructure.
Revocable access
Access granted for a consultation or a delivery can be switched off by the patient at any time.
Patient visibility
The patient can always see what has been shared, with whom, and for how long.
Least-privilege architecture
Systems are designed around minimum necessary access, not maximum convenience for requesters.
Controls in the platform
These are part of the software today.
Roles are enforced on the server
What a person can do depends on a central list of roles and permissions checked on every request, not on which buttons the screen shows.
Each app has its own session
A session for the doctor app cannot be used in the pharmacy or analytics app, even in the same browser.
Support cannot see your records
Support staff see masked search results, verify you with a code, and can help with your account and card. Health records are not available to them at all.
Analytics are separate
Population figures come from de-identified summary tables through a database role that cannot read clinical tables.
Everything sensitive is logged
Access, consent changes, support actions, exports and role changes are recorded with who, when and why.
Emergency override is off
There is no way to bypass patient consent in this version. A request is refused, recorded and reported to the security team.
Where we stand
ArogyaCard is in development. It is not certified, approved or endorsed by any government body, and holds no ABDM, ABHA, HIPAA, DPDP or ISO 27001 certification.
| Area | Status | What we can say today |
|---|---|---|
| ABDM and ABHA compatibility | Evaluating | We are studying how ArogyaCard can work with India's digital health ecosystem. We have no ABDM or ABHA certification and are not affiliated with any government body. |
| FHIR-based health data exchange | Evaluating | The record model is designed so that it can be mapped to FHIR resources. No external exchange is live. |
| DPDP-aligned data practices | Planned | Consent, purpose limitation and access logging are built in. We have not been assessed against the Digital Personal Data Protection Act. |
| Verified provider onboarding | Planned | Doctors, pharmacies and hospitals will be checked before they can use the network. |
| Independent security review | Planned | An external penetration test is planned before any real patient data is handled. |
| Secure NFC card hardware | In progress | Card checks run in simulation today. Secure-chip verification is being integrated and has not been tested on physical cards. |
Questions about security?
We are happy to walk your security or compliance team through the design.
Contact us