Listening First: Why We Bring Clinicians Into the Build
Imagine a world in which healthcare software is so intuitive and seamless that it allows medical professionals to be human.
Over the years, I’ve seen a common pattern repeat itself. Well-intentioned technologies are introduced into clinical spaces—sometimes with great fanfare—but often with little understanding of how care is actually delivered. These tools promise efficiency, precision, or scale. But they too often arrive without context, without continuity, and without consultation.
Instead of reducing burden, they add to it. Instead of enabling care, they interrupt it.
As a clinician, I’ve felt the dissonance firsthand. And I’ve watched colleagues—smart, committed professionals—grapple with technology that seems more attuned to billing requirements than to bedside realities. I’ve also sat in rooms with engineers and strategists who genuinely want to help, but who simply don’t have a clear line of sight into the culture and cadence of clinical work.
This gap—between those who build and those who care—has become one of the defining challenges in healthcare innovation.
As the Chief Medical and Innovation Officer at Reveal Healthtech I made the decision to build what became the Reveal Clinical Network, out of necessity, not strategy. It was born from the realization that we needed a better way to integrate clinical insight into the software development lifecycle—not at the end, not as a checkmark, but throughout.
The goal was never to create a new division or add more layers. The goal was to create relationships—to foster a space where frontline workers could accompany product teams in real time, and where developers could gain firsthand exposure to how care unfolds. We weren’t trying to scale a product. We were trying to scale understanding.
Over time, this effort has grown into a structured learning and engagement program that brings clinicians—nurses, physicians, allied health professionals—into the heart of the design process. It trains them in the basics of the software development life cycle so that they can participate more effectively in technical dialogue. Just as importantly, it is giving our developers exposure to the daily, real-world complexities of clinical care.
The premise was simple: if we want to build technologies that work for healthcare, we need people who understand both.
In the process, we confirmed something that should have been obvious: when clinicians feel heard, they participate differently. They ask different questions, they offer insight before a mistake becomes a feature, and they help surface risks that would otherwise emerge only after deployment—when they’re far more costly, and often irreversible.
On the development side, we are finding that engineers and designers are more energized when they understand the why behind their work. When they see the impact of small design choices on real patients and real workflows, the sense of accountability shifted.
And when both sides begin to speak a shared language—rooted in clarity, humility, and respect—the work becomes more creative, more aligned, and more meaningful.
One of the deeper insights from this work so far has been just how much culture shapes outcomes. Technology doesn’t operate in a vacuum. It lives within systems. And if those systems are misaligned, fragmented, or unjust, the technology tends to reflect that reality.
We’ve seen it time and again—tools that are perfectly functional on paper but fail in practice because they ignore the social and cultural fabric of healthcare. They assume uniformity where there is nuance. They flatten complexity instead of learning from it.
That’s why we insist that our clinical partners be matched to specific use cases—people who not only understand the medicine but the context. People who can translate between lived experience and product design. Their presence helped keep us honest. And human.
In many ways, this entire initiative has been an exercise in building unity—not uniformity, but the kind of unity that emerges from shared purpose. It’s not enough to have great ideas or the best engineers. Without unity of thought and vision, execution will always falter. Without unity of action, even the most promising project can lose its way.
This work has taught me that unity isn’t something you declare. It’s something that emerges through practice—through the structures you build, the conversations you host, and the way you value each contributor. That practice is slow. Sometimes messy. But ultimately, it’s the only path toward solutions that are not only functional, but genuinely useful—and even transformative.
I don’t believe the future of healthcare lies in more tools. I believe it lies in better relationships—between disciplines, between institutions, and most importantly, between people.
We built the Reveal Clinical Network not because we had to, but because we couldn’t ignore the gap any longer. We didn’t want to keep watching well-meaning efforts fall short for preventable reasons. We wanted to build differently—from a place of humility, and a place of service.
This isn’t a perfect system. It’s evolving. But what gives me hope is that we’ve begun to create the conditions for real accompaniment—between developers and clinicians, between ideas and implementation, between intention and impact.
And in that, I see the possibility of something lasting.
Dr. Salim Afshar