The clinician in the code: What co-development looks like in practice

A few months ago, a team of our engineers, designers, and product managers set up in a break room at a few practices in Louisiana and Mississippi. Between patient visits, physicians wandered in, grabbed a chair, and started talking. They weren't reviewing a polished demo or reacting to a roadmap presentation. They were explaining where their day broke down, what slowed them down, and what they wished technology would do differently.  The room stayed loud most of the day, humming with palpable energy that was equal parts clinical complaint and technical debugging, and by the time anyone left, the products and features being described weren’t sketches. They were already being built, right there, so physicians could watch features evolve in real time, challenge assumptions, and push the team in directions they never anticipated.

We saw the same thing again during Boston Tech Week, when clinicians spent the day side-by-side with our engineers, designers, product managers, and data scientists, reshaping AI-powered workflows together.  We didn't leave with a list of feature requests; we left with working code, grounded in everyday clinical realities that is already shaping the product our users touch every day.

In both rooms, the same thing was happening: clinicians weren’t simply evaluating our work — they were doing it with us. That’s the difference between feedback and co-development, and it’s how trust in technology actually gets built.

Co-development isn't another word for customer feedback

"Co-development” has become one of those nice-sounding phrases every health IT company uses. Too often, though, it means inviting clinicians to react to something that's already been designed. That's valuable feedback — but it isn't co-development.  

Real co-development means clinicians, engineers, designers, product managers, and data scientists solving problems together before the solution exists. Each group brings a perspective the others don't. Clinicians understand workflow and patient care. Engineers understand what's technically possible. Data scientists understand what AI can reliably support. Product managers connect those perspectives into something usable. When those conversations happen together instead of sequentially, you don't simply build better features — you solve different problems. The result isn't just software clinicians approve of. It's software they recognize as something they helped create.

Trust should determine the pace of AI

The healthcare industry spends a lot of time talking about how quickly AI is advancing. I think we’re asking the wrong question. It’s not how fast AI models improve. It’s how fast clinicians are willing to trust them.

Research continues to reinforce this reality. Recent surveys from organizations like the AMA, KLAS Research, and Wolters Kluwer consistently show that clinicians want transparency, governance, and meaningful involvement before AI takes on higher-stakes decisions.

We’re experiencing this firsthand. Once we saw that physicians trusted ambient tools to accurately capture a conversation, we could then layer in a next step: pulling together the 10 or 15 documents that can follow a single hospital discharge into one summary, with a link straight back to the source, so a physician isn’t hunting through 50 pages to find the detail that matters. From there we could add an intelligence layer, which would allow a physician to ask a question of a chart or an inbox the way they would ask a colleague. Like stepping stones, each innovation depended on the one before it holding steady, earning enough trust, before the next could be reached. Because of this, we deliberately didn’t build based on what the models were capable of; we built it based on what clinicians were ready to allow AI to augment next. Trust that can’t be verified is akin to no trust at all.

The best feedback is the feedback that changes your roadmap

Perhaps it’s antithetical, but the most valuable moment in co-development isn’t when clinicians validate an idea – it’s when they reject one.  Some of our favorite concepts have died in co-development sessions. This isn’t a failure. It’s so much more valuable to learn at the iteration stage what will, or will not, pass the adoption bar. That's exactly why we bring clinicians into the process so early. Launching an elegant feature that no one trusts or adopts is far more expensive than abandoning a promising idea before it's built.

Those conversations also reveal nuances we rarely would have discovered on our own.  Our clinicians push the gas in some areas and pump the brakes in others, and it’s not always in areas we might presume. They’d like us to go further on personalization, but hold back on automation. They might advocate hard for ambient documentation, but then request an override option so they can still dictate appointment notes word for word. A survey or a focus group captures just one of those directions. Co-development lets you hold both at the same time and build the tension directly into what ships — and what you hold back. It’s part of why we built a standing forum for exactly this kind of exchange. Our EHR AI CoLab brings a small group of clinician partners together on a recurring basis to pressure-test what we’re building — not to validate a finished demo, but to challenge whether the premise behind a feature is right before it reaches broad release.

Building AI clinicians actually want

AI happens to be where this principle is most visible today, because innovation is moving so quickly. But this isn't really an AI story — it’s a product development one. Technology succeeds in healthcare when it fits naturally into the way clinicians think, work, and care for patients. That only happens when clinicians help shape it from the beginning.  The companies that win won't necessarily be the ones with the biggest models or the fastest release cycles.  They'll be the ones that consistently earn the confidence of the people who rely on their products every day.  For us, that means treating co-development as more than a design exercise.  It's how we build... and it's how we decide what to build next. Technology may power the future of healthcare, but clinicians will determine whether that future is trusted. That's what we mean by putting the clinician in the code.