The Vitaloop hospital platform is under development and has no live hospital deployments at present. This policy states the principles we build to and the commitments we will be held to at launch. It describes design intent, not certification. We will update it as the platform is released, and say plainly what is live and what is still planned. Our current regulatory position is on the ABDM & regulatory status page.
The ABDM Health Data Management Policy asks data fiduciaries to publish a privacy-by-design policy that covers six things. Hospitals will be the data fiduciaries for their patients, and Vitaloop their data processor and software provider, so this page sets out both what the platform does for hospitals and what we hold ourselves to. It is separate from our Privacy Policy, which covers this website.
1. Practices and systems designed to avoid harm
The platform is designed so that the safe behaviour is the default one.
- Purpose-scoped consent. Clinical care, ABDM record-linking, ABDM disclosure, insurance claims and any research or secondary use are separate consents. Each can be withdrawn on its own, and none is bundled with another. Consent records are kept in addition to ABDM’s own consent artefacts.
- Least privilege. Access is role-based, scoped to the hospital, and checked on every patient and record request. Roles are reviewed at least twice a year. Sensitive record classes, such as records under the MTP Act, pre-natal diagnostic records and mental-health records, are invisible by default and need an explicit extra grant.
- Emergency access, controlled. “Break-glass” access records the ground relied on, who authorised it and why, and creates a mandatory review.
- Audit trails that cannot be edited. Every read and write of personal data is recorded: who, in what role, which patient, what action, for what purpose and when. The trail is append-only, tamper-evident and designed so that if the audit write fails, the action fails. A separate disclosure log records every release of health information.
- Encryption. Data is designed to be encrypted at rest and in transit, with separate keys for each hospital. See section 3.
- Vitaloop staff access is exceptional. Support access to a hospital’s data is time-limited, approved by the hospital, fully audited and never standing, and uses de-identified data wherever the task allows.
- De-identification at the boundary. Product analytics and service improvement are designed to run on de-identified or aggregated data, not on identifiable patient records.
- Independent testing. Before any ABDM production go-live, the web application is to be assessed by a CERT-In or STQC empanelled security auditor, and reassessed after major changes.
- Incident readiness. See our breach-management procedure.
2. Obligations of data fiduciaries, and how the platform helps
Each hospital, as data fiduciary, is responsible for giving patients a clear notice, obtaining valid consent, limiting use to the stated purpose, keeping and erasing records on a lawful schedule, protecting the data, handling patients’ requests, and reporting breaches. The platform is designed to give hospitals the tools to do this:
- notice templates in plain language, based on the model notices the National Health Authority publishes, for display at reception and in the product;
- consent records for each purpose, and enforcement of ABDM consent artefacts (purpose, record types, date range and expiry);
- a retention and erasure schedule for each record class;
- a register for patients’ requests and the hospital’s grievance officer;
- audit and disclosure logs to show who accessed what, and under what authority;
- support for breach notification.
What Vitaloop commits to as processor. We process patient data only on the hospital’s documented instructions; keep it confidential; bind every sub-processor to equivalent obligations in writing and tell the hospital before we add one; help the hospital answer patients’ requests; tell the hospital without delay if we become aware of a breach; and return or delete the data when the contract ends.
3. Technology and standards
We prefer open, widely used standards. We do not claim certification against any standard unless we hold it; see the status page.
| Area | What we use |
|---|---|
| Health data exchange | HL7 FHIR R4, following the ABDM profiles published by NRCeS; ABDM open APIs and the ABDM consent manager |
| Clinical coding | SNOMED CT, LOINC and ICD-10 |
| Encryption at rest | AES-256 with envelope encryption under a managed key service, with separate data keys for each hospital |
| Encryption in transit | TLS 1.3, with deprecated cipher suites disabled |
| Health information sent over ABDM | Encrypted end to end using ECDH over Curve25519 with AES-256-GCM, following the Fidelius specification |
| Audit | Append-only audit trail modelled on ISO/TS 27789, with a separate disclosure log |
| Sign-in and access | Named accounts, no shared credentials; multi-factor authentication for administrative and privileged roles; session idle and absolute timeouts |
The platform is designed for two deployment models: multi-tenant cloud, and installation on a hospital’s own infrastructure. In the cloud model, patient data is designed to be stored and processed only in India, in the AWS Asia Pacific (Mumbai) region, with any backup copies also kept in India and encrypted. Where a hospital hosts the platform itself, the hospital operates the infrastructure and we supply a security baseline as installer defaults.
4. Protection from collection to deletion
| Stage | What we do |
|---|---|
| Collect | Only what the clinical or administrative purpose needs. Notice first, then consent where consent is the basis. |
| Use | Only for the purpose the patient was told about. Identifiable data is not used for advertising, and is not sold. |
| Share | Only with the patient’s consent, or where a law requires. Through ABDM, each release is tied to a consent artefact and logged. When a consent expires or is revoked, display stops and copies held by the recipient are deleted. |
| Store | In India. Encrypted. Backups follow the same rules as live data. |
| Keep | For the longest period any applicable rule requires for that kind of record. Examples: inpatient records for at least three years; records of a termination of pregnancy for five years; a child’s record until the child turns eighteen. Legal holds override the schedule. |
| Erase | When the period ends and no law or proceeding requires the record, it is erased, including from backups on their next rotation. A refusal to erase must say which record class, which law, and the earliest date erasure could happen. |
5. Transparent processing
- Patients are told, in plain language and before data is collected, what is collected, why, who sees it, how long it is kept and how to complain.
- The platform is designed so a patient can see what is held about them and what has been shared, and can withdraw consent.
- We keep a register of sub-processors and share it with hospital customers.
- We publish our policies, our breach procedure and our regulatory status on this website, and date every change.
6. The patient’s interest at every stage
- We do not sell health information and we do not use it for advertising.
- Anything beyond care and the record-keeping the law requires, such as research or secondary use, needs separate consent, and is by default limited to de-identified data.
- Children’s data has extra safeguards: verifiable consent from a parent or guardian, except where the law permits processing to protect the child’s health. We do not track or profile children.
- Patients can exercise their rights, and complain to the hospital, to us and to the ABDM grievance portal. See Grievance Redressal.
Governance
Nihar Bholane is Vitaloop’s Data Protection Officer and Grievance Officer (shobhit@vitaloop.in). This policy is reviewed at least once a year, and whenever the law, the product or the way we deploy it changes materially.