ElevenLabs: Scribe v2 Medical

ElevenLabs Scribe v2 Medical is a speech-to-text model from ElevenLabs, built as a variant of Scribe v2 that is tuned specifically for clinical and medical terminology. It sits in the transcription category, so its job is converting spoken audio into written text rather than generating conversational replies or reasoning over prompts. If your application involves doctors dictating notes, clinical conversations, or any audio where medical vocabulary matters, this is the model ElevenLabs positions for that work.

The model takes audio as its input and returns a transcription as its output. Its stated capabilities include word-level timestamps, optional speaker diarization, and audio-event tagging. Word-level timestamps let you align each word in the transcript to a point in the audio, which is useful for playback syncing, captioning, or highlighting. Speaker diarization, when enabled, separates who said what across multiple speakers. Audio-event tagging marks non-speech events in the recording. No context length is published for this model, and no request parameters are listed as supported, so you should treat it as a fixed-purpose transcription endpoint rather than one you tune with sampling controls.

The practical uses follow directly from those features. Clinical documentation is the obvious one: transcribing patient encounters or dictated notes where standard speech-to-text models tend to stumble on drug names, procedures, and abbreviations. Diarization makes it suitable for multi-party recordings such as consultations or case discussions, where you need to attribute statements to the right speaker. Word-level timestamps support review workflows, letting a clinician or auditor jump to the exact moment a phrase was spoken. Audio-event tagging helps when the recording contains background sounds that matter for interpreting the transcript.

You call it through api14's OpenAI-compatible API using the model id "elevenlabs/scribe-v2-medical". Because the interface follows the OpenAI format, you can point an existing OpenAI client at api14's base URL and send your audio in the same shape you already use for transcription requests. The model accepts audio input and returns transcription output. No additional request parameters are listed as supported for this model, so keep your requests to the standard transcription fields rather than assuming tuning options like temperature or custom prompts will take effect.

One thing to plan around: the model is audio in, transcription out. It does not accept text prompts as input and does not produce generated text beyond the transcript, so tasks like summarising a consultation, answering questions about a record, or extracting structured fields belong to a text model downstream of the transcription step. If you need a general-purpose speech-to-text model rather than one tuned for medical vocabulary, a standard Scribe variant may fit better. For clinical and medical audio specifically, this model's terminology tuning, timestamps, diarization, and event tagging are the reasons to choose it.