AI Model Strategy at Abridge
Healthcare delivery is complex. Many clinical tasks demand expertise that professionals develop through years of training and practice. For example, in a patient conversation, synthesizing a coherent patient narrative from unstructured dialogue requires clinical intuition developed from years’ clinical experience—distinguishing critical symptoms from casual conversation, identifying subtle clinical cues, and applying clinical judgement on diagnosis.
Building, selecting, and orchestrating AI models that support clinicians in this work is hard because the tasks themselves are hard. No single model is the right tool for all of them, which is why we use both frontier models as well as specialized fine-tuned open-source models within Abridge products.
At Abridge, we have a thesis on how to build for healthcare, and our model strategy follows from that thesis: Healthcare professionals should be able to focus on their patients, not on the technology behind their tools.
The AI ecosystem often frames model selection as a decision customers must make: which model family to use, how much reasoning to enable, and how to balance quality, speed, and cost. In healthcare, clinicians should not have to make those decisions.
At Abridge, selecting and orchestrating the right model for each task is our responsibility, consistent with our commitments to our customers. There is no universally best model. A model that excels at one clinical workflow may be poorly suited to another, and every use case brings its own requirements for quality, reliability, latency, cost, and context. Frontier models, specialized in-house models, and systems that combine multiple models all have an important role to play. When we make model updates that affect system behavior, we communicate the changes through our partner release updates process to keep our partners informed.
Our objective is to deliver the best possible result for each workflow. Sometimes that means using a frontier model; sometimes it means training a purpose-built model ourselves; often it means combining models within carefully designed systems where models harnessed to different components or settings all work in harmony.
This post is the first in a series about our model strategies and tactics. Over the course of this series, we intend to share insight into specific models, how and why we have trained them, and the results that we have measured.
In this first post, we explain why we build in-house clinical models, why doing so is difficult, and how we approach the work. Throughout, we emphasize a simple principle: Clinicians shouldn’t have to think about which model is behind the work. As the underlying technology improves, the product should improve with it, without requiring clinicians or health systems to rethink how they use Abridge.
Capability gap. Frontier models are improving rapidly and are extraordinarily capable. Yet general capability does not guarantee the level of clinical performance required for every specialized workflow. Clinical tasks depend on subtle context, medical language, workflow conventions, and an understanding of what information matters. Even small quality gaps can translate into extra review, corrections, or cognitive burden for clinicians. Training models for specialized clinical tasks enables us to optimize directly for the behaviors and results that matter in real clinical settings. For example, we can train a clinical speech recognition model on medical conversations while explicitly emphasizing medical term recall in the training objective. This way, the model is better equipped to understand clinical context and medical terminologies.
Efficiency. Often with general purpose models, we need to build too much context and scaffolding to guide the model through complex clinical settings, or turn on extensive reasoning in order to obtain the desired outcome. This can be slow and hard to predict. With purpose-built models, we can deliver the necessary capability with lower latency and more predictable performance in our testing. For example, applying frontier models for clinical documentation often requires careful harness design to understand different context and clinical settings, and the generation process can be slow and vary widely within and between use cases. With end-to-end specialized models that understand the clinical context inherently, we can achieve the target result more efficiently and consistently.
Economic sustainability. In addition, the large frontier models can be expensive to run, particularly at healthcare’s scale. Cost matters not only as a business constraint, but as a prerequisite for making advanced capabilities broadly available and economically sustainable.
The underlying problems in healthcare are intrinsically difficult. To support clinicians in their work, such as in the clinical conversation example from above, a model must understand not only the medical language, but also which details matter in the clinical context and how clinically relevant judgement is embedded in the unstructured dialogues. In clinical documentation integrity (CDI) work, for a model to surface relevant ICD-10-CM codes (used to classify and record medical diagnoses, symptoms, and injuries) for coders and clinicians to review, it should be able to reason through a patient’s medical record and understand all the intricacies among tens-of-thousands of ICD-10-CM codes defined in the books of coding guidelines. Furthermore, many clinical problems are multi-faceted. We must ensure that the information we surface is safe and accurate, and that the system is fair and robust.
Good models require good-quality training data, and real-world clinical data is messy and variable. Clinical data varies across clinicians, specialties, care settings, institutions, workflows, and documentation styles. Beyond the inherent subjectivity of what constitutes an ideal output, there is a profound degree of diversity and heterogeneity to wrangle across these various settings. Even if most matters were unanimously agreed upon at a fine-grained level, the contextual heterogeneity still makes getting high-quality training data both technically and operationally challenging.
We start with the user experience and work backward. In close collaboration with our clinical partners, we translate real clinical settings and workflows into concrete requirements for quality, reliability, latency, and cost. These requirements help us determine whether to use an existing model, build a specialized model, or combine multiple models, and which architecture is best suited to the problem.
High-quality data is central to this work. We invest significantly in curating training data from a combination of public datasets, de-identified medical data, and carefully generated synthetic data. For example, in medical coding, we built an audit and feedback process that improves the accuracy of our coding annotations. In clinical conversation understanding, for example, synthetic data supplements real-world data for medical terms that are rare in practice, helping our models handle the full breadth of medical terminology. Each source serves a different purpose, and together they help us capture the complexity and variability of real-world healthcare while upholding our privacy and data quality commitments.
Finally, we build extensive evaluations around the results that matter in practice. We assess not only whether a model performs well on a benchmark, but whether it meets our standards for accuracy, safety, fairness and equity, and usability required in clinical workflows. These evaluations guide model development, help us identify regressions and edge cases, and provide the evidence needed to determine when a model is ready to support clinicians at scale.
Building in-house models is not an end in itself. It is one part of a broader model strategy designed to deliver trustworthy clinical AI with the right balance of quality, reliability, latency, and cost. We use frontier models where they are the best fit, purpose-built models where specialization creates a meaningful advantage, and combinations of models when no single model can meet the full set of product requirements.
Importantly, we believe end-users should not need to consider which models are being used for specific tasks. They should be able to focus on their patients.
We begin with the user experience. By working closely with clinical partners, we translate real workflows into concrete requirements, curate data that reflects the complexity of healthcare, select architectures suited to the task, and evaluate systems against the standards that matter in practice. Each of these steps is necessary: A strong model trained on weak data, optimized for the wrong objective, or measured with an incomplete evaluation, will not produce a trustworthy product.
As we improve our in-house models and the landscape of frontier models keeps changing, our model strategy will continue to evolve. What will remain constant is our focus on the clinician experience. By staying flexible about the models we use and rigorous about the results we measure, we can bring new capabilities to clinical workflows more quickly, predictably, and sustainably.