Privacy Policy

1. Introduction and Philosophy

DocVerb ("we," "us," "our") is built on a privacy-first architecture. This Privacy Policy explains how we collect, use, process, and protect information when you use our AI clinical documentation platform. Our core principle: ultra-minimisation to protect patient identification. We do not build centralized patient identity databases. We process audio transiently to generate documentation, then delete the source. All servers are located in India with no cross-border data processing.

2. Data Controller and Processor Roles

• You (Doctor/Practice) are the Data Controller for Patient Data. You determine the purposes and means of processing.
• DocVerb acts as a Data Processor on your behalf, processing Patient Data solely to provide the Service per your instructions.
• This distinction is legally significant under DPDP Act, GDPR, HIPAA, CDSCO, and other applicable regulations.

3. Information We Collect

3.1 Account Information (Controller: DocVerb)

• Name, email, practice name, professional credentials
• Billing/payment details (processed by payment partners)
• Login credentials (hashed), authentication tokens
• Usage analytics (aggregated, anonymized)

3.2 Clinical Documentation Inputs (Controller: You)

• Audio recordings of doctor-patient consultations (processed transiently)
• Structured outputs: SOAP notes, prescriptions, summaries, follow-ups
• Metadata: timestamps, language, specialty template used
• No Patient Identifiers Stored: We do not collect patient names, IDs, phone numbers, Aadhaar, ABHA IDs, or demographic data as separate fields. Ultra-minimisation to protect patient identification.

3.3 Technical Data

• IP address, device info, browser type, OS
• Access logs, error logs, performance metrics
• Feature usage (anonymized)

3.4 UID Architecture — Anonymised Linkage Model

DocVerb implements a proprietary UID (Unique Identifier) architecture designed to enable continuity of care without ever storing identifiable patient information on our servers:

• Only SOAP notes and prescriptions are stored for future reference — no patient names, numbers, emails, IDs, dates of birth, or any identifying information.
• Only a UID is used as the patient reference. The UID remains with the patient and can be stored on the doctor's personal device (never on DocVerb servers).
• First encounter process: Patient name/details are shown on screen once (attached to the prescription/SOAP note) but are never uploaded to the server.
• UID is not linked to human identification — it becomes anonymous inside the server. The server only sees a pseudonymous UID with clinical content.
• Re-identification is only possible if the UID is shared from the outside world (e.g., by the doctor/patient with explicit consent).
• Doctor ID + Patient UID matching required — without this dual-key match, clinical data cannot be seen or obtained by any party.
• Full identification requires: Doctor ID + Patient UID + UID + timestamp — this quadruple combination is the only way to link data to a specific consultation.

This architecture ensures that even if server data were accessed, it would contain only clinical documentation attached to anonymous UIDs with no path to human identity without external collaboration from the treating doctor and patient.

4. Legal Basis for Processing and Consent Process

DocVerb processes clinical data as a data processor acting under the instructions of the Data Fiduciary (Doctor/Practice). The lawful basis for processing depends on the type of data and purpose:

Data Category	Legal Basis (DPDP/GDPR)	Purpose
Account Info	Contract performance (Art. 6(1)(b) GDPR / Sec. 7 DPDP)	Service provision, billing, authentication
Clinical Inputs	Your instructions as Controller (Art. 28 GDPR / Sec. 8 DPDP)	Generate documentation per your request
Technical Data	Legitimate interest (Art. 6(1)(f) GDPR)	Security, fraud prevention, service improvement
Analytics	Consent / Legitimate interest	Product improvement (aggregated only)

4.1 Consent Process

DocVerb does not directly obtain consent from patients. Instead, the Data Fiduciary (Doctor/Practice) obtains explicit consent from each patient before using DocVerb for their consultations. The consent process includes:

• Doctor-Patient Discussion: The treating Doctor explains how DocVerb works, what data will be processed, and the benefits for continuity of care.
• Written/Documentary Consent: Patients sign a consent form or digitally acknowledge via the clinic's EMR system, specifying the scope of AI assistance and their right to withdraw consent at any time.
• Review and Approval Before Processing: Before processing begins, the Doctor reviews and approves the AI-assisted documentation workflow.
• Editable Workflow: Patients have the option to request human review of AI-generated documentation before finalization. Any edits or overrides are logged with timestamps and attributed to the reviewing Doctor.
• Review Before Export: The Doctor reviews and approves documentation before final export to EMR or other systems.
• UID Consent Binding: Consent is bound to the UID architecture — the patient consents to their clinical data being processed under a pseudonymous UID that only the treating doctor can link to their identity. The UID itself contains no identifying information.

Every consent record is maintained with timestamps by the Data Fiduciary. Every edit is logged with timestamps and attributed to the reviewing Doctor. DocVerb relies on the Data Fiduciary's compliant consent as the lawful basis for processing personal data under Section 6 of the DPDP Act and other applicable regulations including HIPAA, CDSCO, and GDPR.

5. How We Process Clinical Audio (Ultra-Minimisation)

1. Upload: Audio sent encrypted (TLS 1.3) to processing infrastructure in India.
2. Transcription & Structuring: AI models convert speech → text → structured clinical documentation.
3. Output Delivery: Generated documentation returned to your secure session.
4. Automatic Deletion: Source audio deleted within 24 hours of processing completion. No long-term storage.
5. No Training on Your Data: Your consultations are not used to train or improve our models.
6. India-Only Processing: All processing occurs on servers located in India (Mumbai/Bangalore regions). No cross-border data processing.

5.1 UID-Based Data Minimisation Architecture

The UID architecture enforces ultra-minimisation at every layer:

• At input: Patient identifiers (name, phone, email, ID, DOB, Aadhaar, ABHA) are never transmitted to DocVerb servers. They are displayed once on the doctor's screen for verification and attached to the generated prescription/SOAP note locally, then discarded.
• At processing: Only the UID (a random opaque string), clinical audio, and doctor's credentials reach the server. The UID has no semantic link to human identity.
• At storage: Only SOAP notes and prescriptions are persisted, tagged with UID + Doctor ID + timestamp. No patient identity fields exist in the database schema.
• At retrieval: Data is only accessible when the authenticated Doctor presents both their Doctor ID and the Patient UID — a dual-key requirement that prevents enumeration or bulk access.
• At linkage: Cross-consultation continuity requires the Doctor to provide the same UID for a returning patient. DocVerb cannot link consultations across doctors or practices — each Doctor's UID namespace is isolated.

This design means: DocVerb servers never see, store, or process patient identity. The linkage between UID and human identity exists solely on the doctor's personal device and in their clinical judgment.

6. What We Do NOT Do

• ❌ Build centralized patient identity databases
• ❌ Store patient names, IDs, contact details, ABHA/Aadhaar numbers
• ❌ Link consultations across doctors/practices
• ❌ Sell, rent, or license Patient Data to third parties
• ❌ Use Patient Data for advertising, marketing, or profiling
• ❌ Train AI models on your clinical content
• ❌ Share Patient Data with insurers, employers, or government agencies (unless legally compelled with valid process)
• ❌ Process data outside India — all servers in India
• ❌ Suggest or prescribe medicines — we only process conversations to generate documentation drafts for Doctor review

7. Data Sharing and Subprocessors

We engage subprocessors solely to provide the Service. All subprocessors are located in India:

• Cloud Infrastructure: AWS/GCP (India regions) - hosting, compute, storage
• AI/ML Processing: GPU inference providers (India-hosted)
• Payments: Razorpay/Stripe - billing processing
• Communications: SendGrid/Transactional email - account notifications
• Monitoring: Sentry/Datadog - error tracking, performance (anonymized)

All subprocessors execute Data Processing Agreements (DPAs) with appropriate safeguards. Subprocessor list updated at docverb.no.reply@gmail.com.

7.1 UID Architecture and Data Sharing Constraints

The UID architecture fundamentally limits what can be shared:

• No patient identity to share: Since DocVerb never receives or stores patient names, IDs, contact details, or demographics, there is no identifiable patient data to share with subprocessors, insurers, employers, or government agencies.
• Subprocessors receive only: (a) Doctor account data (Controller: DocVerb), and (b) Clinical content tagged with anonymous UID + Doctor ID + timestamp (Controller: Doctor). No patient identity fields are transmitted.
• Government/legal requests: If legally compelled with valid process, DocVerb can only produce clinical documentation tagged with anonymous UIDs. Without the Doctor's UID mapping (held only on the Doctor's personal device), the data cannot be linked to any identifiable patient.
• Cross-doctor/practice isolation: Each Doctor's UID namespace is cryptographically isolated. DocVerb cannot link Patient UID "abc123" from Dr. A to Patient UID "abc123" from Dr. B — they are unrelated opaque strings.

8. International Transfers

All primary processing occurs in India (Mumbai/Bangalore regions). No patient data is processed outside India. We do not transfer patient data outside India for processing.

8.1 UID Architecture and Cross-Border Protections

The UID architecture provides an additional structural safeguard against international transfer risks:

• No identifiable data to transfer: Since patient identity never enters DocVerb systems, there is no "personal data" (as defined by GDPR/DPDP) associated with clinical content that could be transferred across borders.
• Anonymous clinical content only: Even if clinical documentation (SOAP notes, prescriptions) were somehow accessed from outside India, it would contain only UIDs, Doctor IDs, timestamps, and clinical text — no names, IDs, contact details, or demographic data.
• Re-identification requires local collaboration: Linking UID-tagged clinical data to a human requires the treating Doctor's UID mapping (stored on their personal device in India) and explicit cooperation. This cannot be compelled via cross-border legal process targeting DocVerb alone.
• India-only infrastructure guarantee: All DocVerb infrastructure, subprocessors, and data stores are contractually and technically restricted to India regions. No backup, disaster recovery, or analytics processing occurs outside India.

9. Data Retention

Data Type	Retention Period	Deletion Method
Audio inputs	≤ 24 hours post-processing	Automated secure deletion
Clinical Documentation	During active subscription + 30 days export window	Automated deletion post-window
Account Information	During active subscription + 2 years (legal/tax)	Anonymization or deletion
Billing Records	8 years (Indian tax law)	Archival, restricted access
Access/Error Logs	12 months	Automated rollover deletion
Anonymized Analytics	Indefinite (non-personal)	N/A

10. Security Measures

• Encryption in transit (TLS 1.3) and at rest (AES-256)
• Zero-trust network architecture, VPC isolation
• Role-based access control (RBAC), principle of least privilege
• SOC 2 Type II controls (in progress), regular penetration testing
• Incident response plan, breach notification within 72 hours
• Employee background checks, security training, confidentiality agreements
• All infrastructure in India

See our Security page for detailed technical measures.

11. Your Rights (Data Subject Rights)

As Data Controller, you facilitate patient rights. As our user, you have:

• Access: Request copy of your account data
• Rectification: Correct inaccurate account information
• Erasure: Delete account and associated data (subject to legal retention)
• Portability: Export Clinical Documentation in JSON/PDF
• Restriction/Objection: Limit processing of technical/analytics data
• Withdraw Consent: For optional analytics (where consent-based)

Submit requests to docverb.no.reply@gmail.com. We respond within 30 days (DPDP) / 1 month (GDPR).

12. Children's Data

DocVerb does not knowingly process data of children under 18 as patients. Pediatric consultations are processed identically—no age-based data collection. You ensure lawful basis for minor patient data per applicable law.

13. Automated Decision-Making

The Service uses AI to assist documentation drafting only. No fully automated decisions with legal/similar significant effects on patients. All outputs require your professional review and approval before clinical use. DocVerb does not suggest or prescribe medicines — we only process conversations to generate documentation drafts for Doctor review.

14. Data Protection Officer

Contact our DPO: docverb.no.reply@gmail.com (Subject: DPO)

15. Grievance Redressal (DPDP Act)

Per DPDP Act Section 13, you may file a complaint with our Grievance Officer at the above email. If unsatisfied, you may approach the Data Protection Board of India.

16. Changes to This Policy

Material changes notified 30 days in advance via email and in-app. Continued use = acceptance. Version history available on request.

17. Contact

Privacy questions: docverb.no.reply@gmail.com