Privacy Policy

Last updated: May 2026  |  Effective: May 2026  |  Version: 1.2

This Privacy Policy explains how the zonov.ai Chrome Extension ("Extension", "we", "our") collects, processes, stores, and shares information when authorised hospital staff ("User", "you") use the Extension to streamline patient registration in hospital HIMS systems.

1. What the Extension Does

zonov.ai is a hospital productivity tool designed exclusively for authorised medical registration staff. It reduces manual data entry during patient registration by using three AI-powered features:

• Aadhaar / ID Card Scan – The staff member captures the patient's Aadhaar card using the device camera. The image is sent to an AI service for OCR (text recognition). The extracted patient details are automatically filled into the hospital HIMS registration form.
• AI Voice Fill – The staff member speaks additional patient details (mobile number, email, complaints, etc.) into the microphone. The audio is transcribed to text and the relevant form fields are filled automatically.
• Return Patient Recognition – For patients who have visited before, the camera captures the patient's face. A mathematical face descriptor is generated on-device and compared against stored descriptors. If matched, the patient's saved record is retrieved from the database and the form is pre-filled – eliminating the need to re-scan the Aadhaar card.

2. Face Recognition – How It Works

2a. The Face-API Library

Face recognition is powered by face-api.js, an open-source JavaScript library built on TensorFlow.js. All model inference runs entirely within the browser on the hospital staff member's device (CPU-based, no GPU required). The model files (approximately 6 MB) are bundled directly inside the Extension and are never downloaded from external servers.

2b. What the Camera Captures

When face recognition is triggered, the Extension activates the device camera for a live preview. A video frame is captured at the moment of registration or matching. This raw image:

• Is processed entirely on-device by the TensorFlow.js face-api library
• Is never uploaded to any server
• Is never stored locally after the descriptor is computed
• Exists in memory only during the milliseconds of processing

2c. The Face Descriptor

The face-api library extracts a 128-dimensional numerical vector (an array of 128 floating-point numbers) from the face image. This is called a "face descriptor" or "face embedding". It represents the geometry and features of the face as numbers – it cannot be reverse-engineered back into a photograph.

Matching is performed using Euclidean distance – two descriptors are compared mathematically. A threshold of 0.38 is used; descriptors with a distance below this threshold are considered a match. This computation runs client-side in the Extension, not on any server.

2d. What Is Stored

• The 128-number descriptor array is stored in the Supabase database, linked to the patient's record
• The threshold value (default 0.38) is stored alongside the descriptor
• The original camera image is never stored anywhere

2e. Face Matching Flow (Returning Patient)

1. Staff activates "Return Patient" mode
2. Extension loads all stored face descriptors from Supabase into browser memory (cached locally in chrome.storage.local)
3. Camera captures a live frame
4. face-api.js computes the query descriptor on-device
5. Euclidean distances are computed locally against all stored descriptors
6. If a match is found (distance < 0.38), the patient record is fetched from Supabase and the form is auto-filled
7. No face data leaves the device during matching – only the final patient record retrieval is a network call

3. Voice Input – How It Works

3a. What the Microphone Captures

When Voice Fill is activated, the Extension uses the Web Audio API (running in a Chrome Offscreen Document) to capture microphone audio. The audio is recorded using the MediaRecorder API in audio/webm format (typically Opus codec) at mono quality.

3b. Silence Detection

The Extension continuously monitors audio energy levels to detect when the user has finished speaking. Recording automatically stops after approximately 2.5 seconds of silence (configurable) or a maximum of 15 seconds. No continuous or background recording occurs – the microphone is active only while the Voice Fill button is held or clicked.

3c. Transcription

The recorded audio blob is sent as a single HTTP request to the Extension's backend proxy server (extension-backend.zonov.ai), which forwards it to Groq's Whisper API for speech-to-text transcription. The audio file is:

• Sent over HTTPS (TLS-encrypted) only
• Processed by Groq's Whisper model to produce a text transcript
• Not stored by zonov.ai's backend beyond the API round-trip (typically <2 seconds)
• Deleted from the backend immediately after the transcript is returned

3d. What Happens to the Transcript

The text transcript is parsed by the Extension to identify relevant data fields (mobile number, email address, patient complaints, etc.). These values are auto-filled into the corresponding HIMS form fields. The transcript itself is not stored in any database.

3e. Language Support

The Whisper model supports Indian languages including Hindi, Hinglish, Tamil, Telugu, Bengali, and others. The Extension instructs the model to transcribe in English (Latin script) to ensure compatibility with HIMS form fields.

4. Local vs. Cloud Processing

The following table clarifies exactly where each type of data processing happens:

5. Data We Collect and Why

5a. Patient Identity Data (from Aadhaar / ID Card Scan)

When a staff member scans an ID card, the following patient data may be extracted and stored:

• Full name, date of birth, gender
• Aadhaar number (12-digit UID)
• Father's name / guardian name / care-of details
• Residential address, PIN code, district, state
• Mobile number and email address (if present on card or spoken via Voice Fill)

Purpose: To populate the HIMS registration form instantly and to enable returning patient lookup so the same patient does not need to be re-registered on future hospital visits.

Storage: Stored in a private Supabase PostgreSQL database (nnzozslhgdmgnfhtadoq.supabase.co) scoped to your hospital's identifier. Each hospital's data is logically isolated by a hospital_id column with Row-Level Security (RLS) policies enforced at the database level.

5b. Facial Biometric Descriptor

If a patient's face is enrolled for return visit recognition, a 128-dimensional numerical face descriptor is generated and stored in the Supabase database, linked to the patient record. The source photograph is never stored. Full technical details are in Section 2.

5c. ID Card Images (for OCR)

Card images are transmitted to the Groq API for text extraction. They are not stored by zonov.ai or its backend. See Section 6 for Groq's data handling terms.

5d. Voice Recordings (for Voice Fill)

Audio is captured only while Voice Fill is active, sent to Groq Whisper for transcription, and immediately discarded. Not stored by zonov.ai. See Section 3 for full details.

5e. Staff Authentication Data

Staff log in with email and password via Supabase Authentication. Passwords are hashed and managed entirely by Supabase – the Extension never stores passwords. Only the encrypted JWT session token is stored in chrome.storage.local on the staff device.

5f. Form Field Label Memory

The Extension learns which HIMS page input labels correspond to patient data fields to improve autofill accuracy. These label mappings are stored locally in chrome.storage.local and contain only HTML label strings – no patient data. They are cleared when the Extension is uninstalled.

5g. Hospital UHID / Registration Numbers

After a patient is successfully registered in HIMS, staff may save the hospital-assigned Unique Health ID (UHID / Reg No) to link it to the patient's Supabase record.

6. Third-Party APIs and Services

6a. Groq (api.groq.com)

Purpose: AI language model inference for ID Card OCR and Voice Transcription.

Data transmitted: Card image (JPEG/PNG) and/or audio file (WebM/Opus). No patient name, ID numbers, or database records are sent to Groq.

Routing: Requests pass through extension-backend.zonov.ai (a secure backend proxy). The proxy adds the Groq API key server-side – the key is never exposed in the Extension code.

Refer to Groq's Privacy Policy for their data handling commitments.

6b. Supabase (supabase.com)

Purpose: Cloud PostgreSQL database and authentication service. Stores patient identity records, face biometric descriptors, and manages staff authentication.

Data isolation: Row-Level Security (RLS) policies ensure each hospital can only access its own patients.

Refer to Supabase's Privacy Policy for their infrastructure commitments.

6c. zonov.ai Backend Proxy (extension-backend.zonov.ai)

A secure intermediary server that forwards ID card images and voice audio to Groq API server-side. Does not log request content, does not store images or audio files, and does not share data with any other service.

6d. No Other Third Parties

The Extension does not use or transmit data to any advertising network, analytics service, social media platform, data broker, or government service.

7. Data Retention Policy

7a. Patient Data Deletion Requests

Hospitals can delete individual patient records and their associated face descriptors at any time via the zonov.ai dashboard or by contacting support. Upon deletion, the record is permanently removed from the Supabase database and cannot be recovered.

7b. Extension Uninstall

When the Extension is removed from Chrome, all data stored in chrome.storage.local is automatically deleted by Chrome. Patient records stored in Supabase are not affected – they remain until deleted by the hospital administrator.

8. Permissions Justification

9. Security Measures

• Database isolation: Supabase Row-Level Security (RLS) ensures Hospital A's staff cannot access Hospital B's patient records.
• JWT authentication: All database requests include a short-lived JWT token. Expired tokens are rejected.
• API key protection: Groq API keys are stored only on the backend proxy server – never in Extension code, never visible to end users or Chrome DevTools.
• No raw images stored: ID card photographs and camera frames are never persisted – they exist in memory only during the OCR or face-detection operation.
• No audio stored: Voice recordings are processed and discarded after transcription. No audio files are written to disk by zonov.ai.
• Local model files: Face recognition model weights (~6 MB) are bundled inside the Extension package – never fetched from an external CDN at runtime.
• Manifest V3: The Extension is built on Chrome's latest security architecture (MV3), which prohibits remote code execution and limits network access to declared hosts only.

10. Data Subject Rights

Under India's Digital Personal Data Protection Act 2023 (DPDP Act) and GDPR (where applicable), patients whose data is processed have the following rights:

• Right to Access – Request a copy of their stored data
• Right to Correction – Request correction of inaccurate data
• Right to Erasure – Request deletion of their data, including face biometric descriptors
• Right to Restrict Processing – Request that their data not be used for face recognition
• Right to Withdraw Consent – Withdraw consent for biometric data processing at any time

These rights should be exercised by contacting the hospital where the data was registered. Hospital administrators can fulfil deletion requests via the zonov.ai dashboard. For technical assistance, contact arvind@zonov.ai.

11. Consent and Legal Basis

The legal basis for processing patient data through this Extension is:

• Legitimate interest / Healthcare provision – Patient identity data is necessary to register patients in the hospital's HIMS and provide medical services.
• Explicit consent (biometric data) – Face biometric descriptors are special-category data. Hospitals must obtain explicit informed consent from patients before enrolling their face.
• Contractual basis – Staff authentication data is processed to provide access to the Extension under the hospital's service agreement with zonov.ai.

zonov.ai acts as a data processor on behalf of the hospital (the data controller). The hospital is responsible for ensuring patient consent and compliance with DPDP Act 2023 obligations.

12. Changes to This Policy

We may update this Privacy Policy as the Extension evolves. The "Last updated" date at the top reflects the most recent revision. Material changes will be communicated to hospital administrators via email. Continued use of the Extension after changes constitutes acceptance of the revised policy.

13. Contact

For privacy-related questions, data deletion requests, or compliance queries:

• Email: arvind@zonov.ai
• Website: https://zonovai.vercel.app/
• Developer: zonov.ai

© 2026 zonov.ai  |  Privacy Policy v1.2  |  Chrome Extension v1.2.0