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).