Security
Nextvisit GO is built to handle protected health information. Here is the security posture behind it.
Last updated: June 30, 2026
Data in transit
All traffic runs over HTTPS, and the live transcription stream runs over a secure WebSocket. The browser reaches the transcription service using short-lived, scoped tokens minted server-side — the durable API keys never reach the client.
Data at rest
Transcripts and notes are stored in Postgres. Audio is never persisted. Every read is scoped by user and team, and clinical records sit behind non-enumerable identifiers so URLs cannot be guessed.
Authentication and access control
Accounts use email and password with hashed credentials and signed, cookie-based sessions. Application routes that touch clinical data are gated server-side on every request, and role-based access separates team owners from members.
Minimal logging
We never log transcript text, note content, audio, prompts, or model completions. Operational logs carry identifiers and error codes only. The activity log records actions, not clinical content.
Secrets handling
Service credentials are read from the server environment at runtime and are never exposed to the browser or baked into the build. Third-party clients are initialized lazily so a build never requires secrets.
Subprocessors and BAAs
Transcription (Deepgram) and note generation (via OpenRouter) receive session content. A HIPAA-compliant deployment requires Business Associate Agreements with these providers and a configuration that disables data retention and model training.
Reporting an issue
If you believe you have found a security vulnerability, please contact security@nextvisit.example rather than filing a public issue.
This page is a plain-language summary, not legal advice. A production deployment handling protected health information must have these terms reviewed by counsel and backed by signed agreements (including BAAs with any subprocessors).