1. Home
  2. 1Heath
  3. Security and Privacy

How Patient Data Is Protected

What is in place today, what must be in place before a real patient is recorded, and the laws that apply.

Key Points
  • No real patient has been recorded, and none will be until the safeguards on this page exist.
  • Today: encrypted storage on the phone, HTTPS, service keys only in the gateway, signed records that cannot be edited.
  • Each app sees only what its user needs: the pharmacy sees the signed prescription, never the consultation note.
  • Records move between providers only through ABDM's consent flow, encrypted end to end with a fresh key for each exchange[1].
  • Patients can see, correct, erase and nominate someone to manage their data, as India's law requires[2].
  • India's data protection law applies in full from May 2027[3]; 1Heath intends to comply before its first real patient.

Principles

  • 1

    Consent before recording. Specific, informed and revocable, captured at the desk with a versioned consent text.

  • 2

    Collect the least, keep it the shortest. Audio is deleted once the note is signed; the record is kept as long as medical-records rules require.

  • 3

    Never sold, never used for advertising. Patient data is used only for the patient's care and their own record.

  • 4

    Every action leaves a trace. Who confirmed what, with which reason, and when.

  • 5

    No secret on the device. The app never holds a key to an AI service.

What Is in Place Today (Demo)

AreaControlTechnology
Data on the phoneConsultations and signed records encrypted at restSQLCipher encrypted database
Data in transitAll traffic to AI services encryptedHTTPS through one gateway
SecretsService keys stored only in the gateway, rotated on failure, never loggedCloudflare Workers secrets
IntegrityA signed record cannot change; a correction is a new signed versionAppend-only records and audit events
Abuse limitsUsage limits per device and in total on speech and draftingMetering in the gateway
EngineeringSecret scanning and tests on every changeAutomated checks before merge

Before the First Real Patient

These are conditions, not plans. None of them is complete today.

  • Consent architecture that meets the DPDP Act: notice in the patient's language, purpose stated, withdrawal as easy as consent, and a guardian's consent for children.
  • Speech provider settings: data retention set to zero days and model training switched off, with written confirmation of where audio is processed and how it is deleted.
  • Audio deleted after signing, automatically.
  • An India-region server for any record that leaves the phone.
  • Person-bound signing: the demo uses a slide to sign; production will need a control that ties each signature to the registered doctor, and a check that electronic signatures are valid under the IT Act.
  • Access control: each app sees only its part; the pharmacy sees the prescription, never the note.
  • An ethics and legal review of recording real consultations, including whether an ethics committee is needed.

Who Sees What

DataDoctorDeskPharmacyPatient
Audio of the consultationUntil signed, then deletedNeverNeverNever stored
Consultation note and diagnosisYesNoNoYes, in their language
Signed prescriptionYesNoYesYes
Allergies and current medicinesYesNoAllergy flags onlyYes
Contact details, vitals, consentVitalsYesName and phoneYes
PaymentsNoYesTheir ownTheir own

Encryption and Keys

  • On the phone: the record database is encrypted with SQLCipher (AES-256). Before the pilot, its key moves into the phone's hardware-backed keystore.
  • In transit: HTTPS with modern TLS to a single gateway; the app talks to no AI service directly.
  • Between providers: ABDM exchanges health records with a fresh key pair for every request: both sides use elliptic-curve key agreement (Curve25519), derive a 256-bit key, and encrypt the record with AES-GCM, so even the exchange in the middle cannot read it[1].
  • Service keys: held only in the gateway's secret store, rotated, never logged, never shipped in the app.

The Patient's Rights

Right under the DPDP ActHow the patient uses it in 1Heath
Information about processing (section 11)[2]A plain-language list of what is held, who has seen it and why
Correction and erasure (section 12)Request a correction (the doctor signs a new version; the old one stays in the audit trail as medical law requires) or erasure where no law requires keeping it
Grievance redressal (section 13)A named grievance contact, with escalation to the Data Protection Board
Nomination (section 14)Name a family member to manage the record if the patient dies or cannot act
Children's data (Rule 10)A parent's verifiable consent before a child's record is created[4]

What Could Go Wrong, and the Control for Each

Some controls are built; the rest are conditions for the first real patient, as listed above.

ThreatControl
A lost or stolen phoneEncrypted database, device lock required, remote sign-out, short session lifetimes
Someone signs as the doctorPerson-bound signing with a PIN or biometric before production; every signature logged with time and device
A staff member browses recordsRole-based access; every view logged; patients can see who opened their record
The AI invents a medicine or doseThe rules engine checks every line against the words spoken; unverified lines cannot be signed
Malicious text in a transcript tries to steer the AIThe model only drafts; it cannot act. Output is parsed into fixed fields and verified by rules
A vendor keeps or trains on audioZero-day retention and training off, confirmed in writing before any real patient
A leaked service keyKeys only in the gateway; usage caps; automatic rotation; secret scanning on every code change
A breachWritten response plan; notify patients and the Board, with a detailed report within 72 hours[5]

Laws and Standards That Apply

Law or standardWhat it requiresWhen
Digital Personal Data Protection Act 2023 and Rules 2025Notice, consent, security safeguards, breach notification, data retention and erasure, parental consent for children; penalties up to ₹250 crore per breach[6]Consent-manager rules from November 2026; most obligations from May 2027[3]
CDSCO guidance on medical device softwareSoftware with a medical purpose is regulated in risk classes A to D; pure record-keeping is generally excluded, but each function is judged separately[7]Issued 21 July 2026; 1Heath will seek a classification opinion, because its safety checks may count
ABDMRegistered facilities and professionals, FHIR records, consent-based exchangeBefore records are shared between providers
Medical ethics and prescription rulesRegistration number, generic names in capitals, patient details, total quantityBuilt into the prescription format
Information Technology Act 2000Rules for electronic signatures and recordsBefore signed prescriptions are used in practice
ISO 27001An audited information-security management systemPlanned within the first six months of funding

This page is a summary for readers, not legal advice. 1Heath will obtain a written legal opinion before any real patient data is processed.

If Something Goes Wrong, and How Long Records Are Kept

  • Breach reporting. Under the DPDP Rules, a breach must be reported promptly to every affected person and to the Data Protection Board, with a detailed report to the Board within 72 hours[5]. 1Heath will have a written breach plan before its first real patient.
  • Record keeping. Doctors must keep in-patient records for three years and provide copies within 72 hours of a request[8]. 1Heath will keep signed records at least as long as the law requires, delete audio once a note is signed, and let patients see and request a copy of their own record at any time.

The Emergency Card and Privacy

The emergency card is readable without unlocking the phone, so the patient chooses exactly what it shows. The default is blood group, allergies, long-term conditions, current medicines and two family contacts. Nothing else on the phone is exposed.

Sources

  1. ABDM developer guide (community-maintained). Implementation guidelines for encrypting and decrypting FHIR data. kiranma72.github.io
  2. TCSA. DPDP Act data principal rights, sections 11 to 14. tcsa.in
  3. AZB & Partners. India's Digital Personal Data Protection Act: phased rollout and key compliance milestones. azbpartners.com
  4. Digital Personal Data Protection Rules, 2025, Rule 10: verifiable consent for processing personal data of a child. dpdpa.com
  5. Digital Personal Data Protection Rules, 2025, Rule 7: intimation of personal data breach. dpdpa.com
  6. YourStory. Govt notifies Digital Personal Data Protection Rules 2025; rollout stretched over 18 months, November 2025. yourstory.com
  7. Nishith Desai Associates. From code to compliance: decoding India's medical device software guidance (CDSCO guidance of 21 July 2026). nishithdesai.com
  8. Indian Medical Council (Professional Conduct, Etiquette and Ethics) Regulations, 2002, clauses 1.3.1 to 1.3.4 (Indian Journal of Medical Ethics reprint). ijme.in