What a Physician-Builder Actually Builds: Inside Clinical Decision Support
- Aug 5
- 6 min read
Many physicians in our online physician communities are enthusiastic about tech products that solve real world problems or make workflows more efficient. Even if these doctors cannot program solutions themselves, they are often the best equipped to provide feedback, insights, and ideas to those at innovative healthcare companies with the technical expertise to create these solutions. Below, we’ll cover how an actively practicing doctor can offer valuable insights at every iteration of a company’s products, and why it’s important to get the input of not just one, but multiple, clinicians when trying to create products that can scale across different environments and clinician preferences.
This article continues our series written by physician builders in prominent positions in tech, which aims to showcase how doctors are now essential to building successful AI products and to offer tips for how other physicians can get involved in health innovation. The article below was written by Dr. Chase Yarbrough, a physician builder at Abridge, a longtime sponsor of the Physician Side Gigs community.
Disclosure/Disclaimer: This page contains information about our sponsors and/or affiliate links, which support us monetarily at no cost to you. These should be viewed as introductions rather than formal recommendations. Our content is for generalized educational purposes. While we try to ensure it is accurate and updated, we cannot guarantee it. We are not formal financial, legal, or tax professionals and do not provide individualized advice specific to your situation. You should consult these as appropriate and/or do your own due diligence before making decisions based on this page. To learn more, visit our disclaimers and disclosures.
Article Navigation
How Physician Builders Provide Insights for Engineers at Tech Companies
A few months ago, I had the privilege of sitting down for a filmed roundtable at my company with another physician builder and two product leaders. The topic was Clinical Decision Support (CDS), a new product that surfaces evidence-based information during the patient encounter from trusted sources like the New England Journal of Medicine, JAMA, and other leading medical journals and association guidelines. You can ask it a question at any time during the visit and its response will be informed by the context of the clinical conversation.
This was a full-circle moment for me. It was only a few months prior that we had started work on this new AI feature, and now we were having a very public retrospective discussion (the roundtable has since been published on YouTube). Something was said by one of my colleagues—Chaitanya Asawa, head of AI engineering for the project—that stuck with me:
“When I don’t have those real-world earned insights, I’m always looking for a way to get them.”
In this case, I was the “way.”
He went on to explain, "If I'm not my own user, I'm always looking for the gap. What is the gap? What are the insights that I don't have? And I think this is why the clinician-in-the-loop model at Abridge is so relevant."
At Abridge, all new products are developed with physicians and engineers working hand-in-hand to build something that is both clinically useful as well as technologically sound. So when a doctor uses it in a clinical environment, it just works.
This is the second in a series of articles written specifically for the Physician Side Gigs community. In this article, I will explain exactly how physician insight is crucial at every step of the process, how that insight actually impacts a product used by tens of thousands of physicians every day, and where my own judgement was incorrect and how our process ensured we got to the right answer anyway.
The Feedback Loop Only a Physician Can Close
The fundamental problem with building clinical AI without physicians is that engineers may not know if the output is correct, whether it’s a clinical note, orders, or the response to a contextual clinical question.
As a physician, you can probably intuit what healthcare software was built with you in mind, and which wasn’t. An engineering team can make changes to a product that surfaces a response to a clinical question, rerun it, and have no way of knowing whether what they did made it better or worse. Clinically, a response can be beautifully formatted and confidently wrong, and nothing in the code will tell you that if you don’t have the training and experience of a physician.
When someone building the product knows what the output should look like, the feedback loop is immediate. I can read a CDS response and know within seconds whether it's what I'd trust at the bedside, and, importantly, whether it’s better or worse than the last round of iteration on the product.
It helps that I've sat on both sides of that desk. I'm a hospitalist, trained in internal medicine and pediatrics, and I still practice. I also studied computer science as an undergrad and worked as an electronic health record developer before medical school. I speak enough of the engineers' language to be useful in their process, and I’ve practiced enough medicine to know when their process has produced something I wouldn't use on a patient.
What ‘Trusted’ Evidence Actually Means
When developing CDS, my expertise extended beyond answering the question, “is this output accurate?” Before even getting to the response to a clinical question, we had to answer a more fundamental question: What does “trusted” evidence actually mean?
Abridge CDS is grounded in a wide range of gold-standard sources, like the New England Journal of Medicine and JAMA. In addition, we’re now incorporating specialty journals and guidelines from organizations like the American Heart Association, American Diabetes Association, American Family Physician, Journal of Clinical Oncology, and Neurology, with more being added regularly.
Within each of these content sources, not all evidence has equal weight for each clinical situation.
Is the right source a specialty society guideline? The primary literature? A review article? An opinion piece? Those carry very different weight at the point of care, and knowing how to rank them, and when, is not a question an algorithm can settle on its own.
This clinical input shaped CDS at every level: which content partnerships we pursued, how the search prioritizes across those sources, and how results are displayed to a working clinician. The scarce ingredient here is clinical expertise and taste, knowing what the output should look like before it exists.
Where My Own Judgment Was Lacking, Even as a Physician
Early versions of CDS reflected my personal preferences. I like my clinical information verbose and comprehensive, so that's how CDS responded: thorough and exhaustive. Then we put it in front of the other clinicians at Abridge for internal testing, and they disliked it. Too long, too much, not what a working physician wants mid-encounter. We made it more concise.
I include this story because it's the most honest illustration of how this actually works. The clinician-in-the-loop model isn't about installing one doctor's instincts into a product. It's a process, with many clinicians testing, disagreeing, and correcting each other, so that no single perspective, including mine, becomes a blind spot.
The same loop extends far beyond our walls. When we launched CDS, it incorporated the patient conversation into its responses, but did not have access to the full electronic health record. Users across the country told us that this would make CDS far more useful. We made it a priority. If your institution uses Abridge, your feedback is part of how this product gets built.
How to Get Started in Health Technology (While Retaining Your Clinical Practice)
AI tools have made it so that anyone can build. What they can't supply is what physicians already have: domain expertise and taste, informed by the lived knowledge of what a meaningful product looks like inside a real healthcare system. Doctors are at an incredible advantage in technology development right now, and I'm not sure enough of us know it.
You don't have to choose one world, either. I still see patients in the hospital, where the impact of my work is direct and human and right in front of me. At Abridge, what I build scales to millions of patient encounters. That’s not to say it isn’t challenging—this is one of the most challenging periods of my career, but it’s also among the most rewarding.
The first step may not require making a drastic change in your life. When your organization evaluates or pilots new software and AI products, get involved. Be the physician in the room who knows what the output should look like. Many third-party companies that work directly with AI platforms are also looking to leverage clinical expertise. Your clinical experience and the challenges you encounter caring for patients are valuable assets you can use to inform the next wave of clinical AI innovation.
Want to hear more directly from the source? Join Abridge physicians, including Dr. Yarbrough, for a live panel-style webinar with Physician Side Gigs this August, with open Q&A. They’ll share how they got started in health tech, how they landed their jobs at Abridge, and their tips for other physicians who want to explore similar pathways or other avenues in tech. Register here.