pediatric-ai-scribe-v3/docs/speech.md

Speech: STT, TTS, Audio Backup

Transcription

POST /api/transcribe accepts multipart/form-data with one audio file up to 25 MB. Server STT is routed through LiteLLM.

Set TRANSCRIBE_PROVIDER=litellm, LITELLM_API_BASE, and LITELLM_STT_MODEL. Auto mode also uses LiteLLM when the gateway is configured.

The model for a request is users.stt_model (the person's own choice), then the stt.model setting, then LITELLM_STT_MODEL. A user's choice wins, so the Settings picker must never offer a model the gateway does not have: it lists what /model/info advertises as audio_transcription (discoverSTTModels() in src/utils/sttProvider.js, cached five minutes). LITELLM_STT_MODELS is a fallback for when discovery fails and is not a list of models known to work — its ids do not resolve on every gateway.

Provider	Notes	HIPAA posture
LiteLLM	Sends audio through the configured LiteLLM /audio/transcriptions backend.	Depends on the selected upstream.

Browser Whisper and browser-local Whisper workers are not part of the runtime. Do not add browser model downloads or Transformers.js STT back into the public app.

Web Speech Preview

Browser-native Web Speech can show interim text when the user explicitly enables it. It is browser/vendor dependent, may send audio to browser-provider cloud services, and should not be treated as the final clinical transcript.

Text To Speech

POST /api/text-to-speech returns audio from LiteLLM /audio/speech. The X-TTS-Provider response header identifies the LiteLLM model used. Requests are limited to 5000 characters.

Provider	Notes
LiteLLM	Uses LITELLM_TTS_MODEL and LITELLM_TTS_VOICE.

The admin/user voice pickers read available LiteLLM-compatible voices from LITELLM_TTS_VOICES.

Recording

A recording holds a screen wake lock for as long as it runs, so the screen going to sleep cannot suspend it. Browsers release the lock whenever the page is hidden, so it is requested again when the page becomes visible; a lock is never requested while hidden, because that request is rejected. The count is shared, so two recorders cannot release each other's lock. A browser that denies or lacks the API keeps recording without one.

Recording continues while the user moves around the workspace — the app is a single page and switching tabs does not touch the recorder. Signing out stops it and releases the lock; nothing is sent, because the session that owned the audio is gone.

AudioRecorder.start() on a running recorder is a no-op. Calling it again would replace the MediaRecorder and drop everything captured so far.

A recording can stop without anyone pressing Stop: the recorder can error, and the microphone can be claimed by another app, unplugged, or revoked. Both are reported once and dispatch audio-recorder-failed, which runs the same path as Stop — so the audio is transcribed and stored rather than left in a tab that still claims to be recording. Whatever was captured before the failure is kept.

Audio Backup

Every recording is kept for 24 hours, whether its transcription succeeded or not. POST /api/transcribe already holds the audio, so keeping it costs no second upload; a storage failure there is logged and the transcription still returns, because losing the transcript someone is waiting for would be worse than losing the copy.

src/utils/audioBackupStore.js is the only place that knows how a recording is kept, shared by /api/transcribe and /api/audio-backups so the two cannot drift apart.

• Audio is gzipped, then AES-256-GCM encrypted (DATA_ENCRYPTION_KEY), before it is stored — in either backend.
• Object storage is used when AUDIO_BACKUPS_S3_* is set; otherwise the payload goes in the audio_backups.audio_data column. Metadata (owner, module, sizes, expiry) is always in Postgres, so listing, ownership and expiry behave the same either way.
• Object keys are recordings/<user id>/<timestamp>-<random>, scoped to their owner, so a leaked id cannot address someone else's audio.
• Reads carry user_id and expires_at > NOW() in the query, so an expired or borrowed id reads as missing rather than as another person's recording.
• The expiry sweep (cleanupExpired in src/db/database.js) deletes each object with its row, so audio cannot outlive its 24 hours in the bucket.
• Rows written before encryption was added are passed through unencrypted on read, so old backups still play.
• The Settings list can retry, download or delete a recording. Download is how a copy leaves the app — onto a phone's Files, a shared drive, an external recorder. It works for both server-side and browser-fallback copies, and a browser copy is only handed to the account that owns it.
• Browser fallback storage (IndexedDB) is used only when the server cannot be reached at all.

Treat audio backups as sensitive clinical data even when encrypted.

Switching audio backups to MinIO

Storing every recording, rather than only the failures, makes object storage the better home. It is off by default because it needs a bucket and its own credentials; the existing generated-images key is scoped to that bucket and cannot reach another.

1. Create an audio-backups bucket and a user with read/write/delete on it.
2. Give the bucket a 24-hour expiry lifecycle rule, as a backstop for objects the sweep could not delete.
3. Set AUDIO_BACKUPS_S3_ENDPOINT, AUDIO_BACKUPS_S3_BUCKET, AUDIO_BACKUPS_S3_REGION, and either AUDIO_BACKUPS_S3_ACCESS_KEY_FILE / AUDIO_BACKUPS_S3_SECRET_KEY_FILE (preferred — credentials stay out of the process environment) or AUDIO_BACKUPS_S3_ACCESS_KEY / AUDIO_BACKUPS_S3_SECRET_KEY.

New recordings then go to the bucket. Rows already in Postgres keep working: a row without storage_key is read from the column.