Security and compliance
Private by design, documented for procurement.
This page separates three things a trust page often blurs: what the system is designed to do, what we control during a pilot, and what an independent party has verified. Where something is not yet verified, we say so.
Where data lives and moves
Records stay in India. Every other hop is listed.
Consultation records are stored in Mumbai. Speech recognition and drafting use the providers listed below, and the patient is told who they are before every recording. Private cloud and on-premise deployments are scoped with each hospital.
| Data | Where it goes today |
|---|---|
| Audio | Streamed over TLS while the doctor records, to WearSynapse's transcription relay and on to a speech-recognition provider. Held in memory only and never stored by WearSynapse in the cloud. Recordings pulled from the pendant onto a doctor's Mac are encrypted and deleted with the consultation. |
| Transcript | Produced by the speech-recognition provider, returned to the doctor's app, and stored encrypted on the device and in WearSynapse's database in Mumbai. |
| Note, prescription and insights | Drafted by an AI model from the reviewed transcript, then saved in Mumbai only after the doctor reviews them. Nothing is filed to the HMS before the doctor approves it. |
| Who holds the keys | WearSynapse AI operates the service. Every request is tied to a signed-in doctor who is an active member of the hospital, and each hospital's records are separated at the database level. |
Sub-processors
| Provider | Purpose | Location |
|---|---|---|
| Supabase | Database and sign-in | India (Mumbai) |
| Vercel | Web app and API | India (Mumbai) |
| Deepgram | Speech recognition (India endpoint, opted out of model improvement) | India (Hyderabad) |
| Sarvam AI | Speech recognition for Indian languages | India |
| Railway | Transcription relay (audio in memory only) | Outside India |
| OpenAI | Drafting notes, prescriptions and insights (requests not stored for app use; abuse-monitoring logs up to 30 days) | United States |
| Modulate | Live speaker separation, enabled only under a signed no-training agreement | United States |
Hospitals are told before a sub-processor is added or changed. Data processing agreements with each provider are being put in place.
Controls
Six controls your IT team will ask about first.
Encryption
TLS for everything in transit. The database is encrypted at rest, and app data on iPhone, Mac, Android and Windows is encrypted with AES-256-GCM using a key that never leaves the device.
Access and roles
Every request is tied to a signed-in doctor who is an active member of the hospital. Owner, admin, reviewer and doctor roles are enforced in the database, and two-factor sign-in for administrators is being rolled out.
Audit log
Administrative actions, record erasures and consent withdrawals are logged with who did it and when. The hospital administrator can read the log, and entries survive account deletion.
Retention
Consultation audio is not stored in the cloud. Transcripts, notes and prescriptions follow the hospital's record-retention obligations; deleted hospital records are hidden and kept unless the hospital approves erasure.
Consent
The app will not record until the doctor confirms the patient's consent, how it was given and in which language. If the patient withdraws, the transcript, note and prescription for that visit are cleared.
Clinician approval gate
Every AI-generated note, prescription line and follow-up is provisional until the treating doctor signs it. Nothing is filed to the HMS before that event.
Readiness, stated plainly.
A design goal is what the system is built to do. A pilot control is something we agree and document with your hospital before clinical use. Verified means an independent party or a standard confirms it. Not claimed means exactly that.
DPDP Act, India
Pilot controlThe hospital is the Data Fiduciary and WearSynapse AI the Data Processor. Patient consent is captured in the app for every consultation; rights handling and incident obligations are set out in the data processing agreement.
ABDM / ABHA
Design goalDesigned for ABDM. Validated only where exchange is in scope for the deployment. The hospital's HMS stays the Health Information Provider; WearSynapse AI never handles ABHA tokens.
FHIR R4
Pilot controlThe HMS integration API is built on FHIR R4. Encounters arrive as transaction bundles with deterministic ids, so a re-post updates rather than duplicates. Enabled per deployment.
ISO 27001 / SOC 2
Not claimedNo certification badges appear on this site until an independent certification or attestation is complete. Ask us for the current status.
Penetration testing
Not claimedNo independent penetration test has been completed yet. One is planned before general availability, and its summary will be shared under NDA.
Data residency
Pilot controlRecords are stored in India. Speech recognition uses India endpoints where available. Drafting, live speaker separation and the transcription relay currently run outside India and are listed under sub-processors.
Documents available on request
Sent to your IT, privacy or procurement lead under NDA where needed.
- Data processing agreement
- Sub-processor list
- Retention and deletion policy
- Incident response and breach notification process
- Architecture diagram
- Business continuity notes
Breach and incident process
The same six steps, whoever finds the problem first.
- 1
Detect
Monitoring, hospital report or disclosure email.
- 2
Contain
Revoke affected keys, isolate the affected deployment.
- 3
Assess
Scope, data classes and patients or doctors affected.
- 4
Notify
The hospital's named contact within the window in the agreement.
- 5
Remediate
Fix, verify and restore normal service.
- 6
Report
A written post-incident report to the hospital.
Responsible disclosure
Found something? Tell us first.
Email human@wearsynapse.com. We acknowledge reports and keep you informed until the issue is resolved. A security.txt and a published response window will follow before production clinical deployment.
Please include
- The affected surface: pendant, app, API or website
- Steps to reproduce
- Potential impact as you understand it
- How we can reach you
Please do not
- Access or retain any patient data
- Disrupt a hospital deployment or the service
- Publicly disclose an unresolved issue
Bring IT, privacy and clinical into the same review.
One walkthrough answers the security questionnaire, the DPA and the workflow questions together.