Clinical language is a specialized domain. The vocabulary that physicians use during patient visits - anatomical terms, drug names, diagnostic codes, clinical procedure names, eponymic syndromes, subspecialty jargon - is not well represented in the general text that large language models are trained on. A model trained on internet text knows what "hypertension" means. A model that can reliably distinguish between "paroxysmal supraventricular tachycardia" and "paroxysmal atrial tachycardia" in spoken clinical audio, transcribe both correctly, and place each in the right section of a structured note has a different and more specific capability.
This article describes the approach Scribemarrow takes to building language models that handle clinical terminology reliably. Not the specific model architecture (which is proprietary) but the principles and methodology behind it, which reflect how we think about the problem of clinical vocabulary in ambient documentation.
The three distinct problems in clinical language
Clinical language processing in the context of ambient documentation has three components that require separate thinking, even though they happen in sequence.
The first is transcription accuracy: does the model correctly convert spoken audio to text, handling the specific phonological characteristics of medical terminology? "Metoprolol" and "metformin" are different drugs with different indications that sound similar enough in running speech that transcription errors are consequential. Medical eponyms - McBurney's point, Virchow's triad, Babinski sign - follow pronunciation patterns that a general speech model may not have seen frequently enough to handle reliably.
The second is semantic understanding: does the model understand the clinical meaning of the transcribed terms well enough to place them in the right section of the note? A physician saying "he reports worsening knee pain when descending stairs" is providing subjective content that belongs in the Subjective section. A physician saying "there is crepitus on patellofemoral compression" is providing an objective examination finding. These require different section placements, and the distinction depends on understanding what the words mean in a clinical context, not just that they are words about knees.
The third is generalization: can the model handle terminology it hasn't encountered frequently in training? Clinical practice includes rare diagnoses, newly described syndromes, recently approved medications, and institutional naming conventions that may appear in a physician's practice even though they are uncommon in any corpus. A model that fails when it encounters unfamiliar terminology is a model that is narrower than the clinical practice it is meant to serve.
Specialty-specific vocabulary depth
Clinical vocabulary is not uniform across specialties. A family medicine practice uses a different vocabulary distribution than an endocrinology practice or a sports medicine practice. Medication names in primary care include common antihypertensives, statins, oral hypoglycemics, and antibiotics - broadly familiar terms. Medication names in oncology include a much higher proportion of complex chemotherapy agents with unusual names that general transcription models handle poorly.
Scribemarrow is built for outpatient primary care and internal medicine - the documentation volume and need is highest there, and the vocabulary range is broad but not the hyperspecialized depth of subspecialty medicine. We have invested in training data and terminology coverage that reflects this focus: the vocabulary of a primary care physician seeing patients for hypertension, diabetes, COPD, depression, musculoskeletal complaints, and preventive care.
This focus matters because it affects model quality in the domain where we operate. A model trained on general clinical text may perform well on inpatient notes and poorly on outpatient primary care notes, or vice versa. The right question for a practice evaluating any ambient documentation tool is: was this model trained on visit audio and notes from my specialty and practice type, or on a broader and less specific clinical corpus?
Drug name transcription: a specific challenge
Drug names are a particularly instructive case for clinical language model training. There are approximately 10,000 prescription drugs with active US market presence, plus generics that may be referred to by multiple names. Drug names are phonologically irregular - they are typically constructed to be distinctive, not to follow natural language sound patterns - and many have both brand and generic names that are used interchangeably in clinical speech.
When a physician says "she's been on Jardiance for about eight months" and then later says "we're going to add empagliflozin" to a different part of the note, the model should understand that these refer to the same drug. When a physician says "stop the metoprolol tartrate and start metoprolol succinate" - two formulations of the same drug with different pharmacokinetics - the model must preserve the distinction rather than collapsing them.
Drug name coverage requires specific training data that is different from general clinical text training. We maintain an active drug name vocabulary that is updated as new medications receive FDA approval, and we test transcription accuracy specifically on drug name audio as part of our model evaluation process.
Handling physician speech patterns
Physicians don't speak during patient visits the way clinical documentation reads when it's written. There are hedge words, pauses, corrections, parenthetical asides to the patient, and mid-sentence restarts. A physician examining a patient's abdomen may say "I'm going to press here... let me know if this is tender... that feels soft, no rigidity" - a mix of instruction to the patient, clinical observation, and documentary narration.
A model that takes this input and generates a clean objective section ("Abdomen soft, nontender, no rigidity") is doing something more complex than transcription. It is filtering the documentary content from the interactional content, identifying what belongs in the note and what belongs in the visit conversation, and organizing the documentary content into the expected clinical format.
This filtering capability - distinguishing physician-patient conversational content from clinical documentation content - is something we have worked to make robust. Errors in this filtering produce notes with conversational artifacts ("let me know if this is tender") in place of clinical documentation language, which require physician editing and erode trust in the tool.
Continual evaluation on real visit types
The way we evaluate model performance is not primarily through benchmark tests on standardized data sets, but through ongoing evaluation on the actual visit types our users encounter. For each major visit type in our practice user base - hypertension follow-up, diabetes management, upper respiratory infection, musculoskeletal complaints, annual wellness visit, new patient intake - we maintain a set of evaluation cases that reflect the vocabulary, complexity, and documentation structure typical of that visit type.
Model updates are evaluated against these visit type benchmarks before deployment. A model update that improves performance on one visit type and degrades it on another doesn't ship until both are passing. This is not a novel methodology - it's standard practice in applied ML - but it is worth describing because it reflects our belief that the right performance target for clinical documentation models is the actual visit mix of the practices that use them, not a general clinical benchmark that may not reflect that mix.